Skip to main content
AI Platform is required infrastructure in 5.5+. At startup, the integration-designer core service unconditionally opens gRPC channels to the Agent Builder (flowx.agent-builder.host/flowx.agent-builder.port) and Knowledge Base RAG (flowx.kb-rag.host/flowx.kb-rag.port) services β€” there is no @ConditionalOnProperty flag to skip them. These properties default to the in-cluster service names (agent-builder, knowledgebase-rag starting with 5.9.2; ai-platform-agent-builder, ai-platform-knowledgebase-rag on 5.9.0/5.9.1), so the service starts out of the box, but AI workflow nodes and knowledge-base retrieval fail at runtime unless those services are reachable.To run FlowX without AI features, you still need to deploy the AI Platform chart (or point the env vars at reachable stub endpoints). Hiding AI surfaces (the AI floating action button, Chat UI component, AI agents) is controlled separately and has two paths:
  • Globally β€” deployment-level kill switch. Point the AI service-name properties on the admin service at services that are not deployed in your environment. The /api/init response then reports the corresponding flag as false under environmentConfiguration.admin-mngt, and the Designer hides the matching AI surfaces for everyone regardless of role. This is the right option for deployments that do not use AI at all.
  • Per-user β€” role permissions. Strip the AI permission keys (aiagent_edit, org_ai_providers_*, wks_ai_models_*) from specific roles via the role-mapper. See the Complete roles & permissions matrix.
Both gates apply: an AI surface appears only when its availability flag is true and the user has the matching permission.
Starting with FlowX.AI 5.9.1, AI availability is split into two independent flags so you can enable runtime AI and build-time AI separately. The single aiServiceName property (and its ai-is-enabled flag) is replaced by:Point a property at a service that is not deployed to turn off that group of AI surfaces. To turn off all AI, set both.

Overview

The AI Platform consists of two layers:
  • Python services β€” AI agent and orchestration services for planning, code generation, analysis, design, knowledge retrieval, and embeddings (REST + gRPC)
  • Event-driven workers β€” Background services consuming Kafka topics for knowledge-base indexing
All inter-service communication uses gRPC with Protobuf contracts, except the config-time agents (AI Developer, AI Analyst, AI Designer) and Agent Builder, which expose REST endpoints.

Infrastructure requirements

Qdrant

Vector database for embeddings. Cluster mode recommended for production.

S3-compatible storage

Object storage for binaries and files. Any S3-compatible provider works (MinIO, AWS S3, etc.).

Kafka

Message broker for event-driven communication. KRaft mode supported.

Keycloak

Identity provider for OAuth2 authentication across all services.

SpiceDB

Fine-grained authorization system for access control.

Service architecture

The AI Platform is a set of Python services. In Kubernetes, every service listens on port 9100 (set via the SERVICE_PORT variable).
Starting with 5.9.2, AI Platform services are deployed under the plain names shown above β€” the ai-platform- prefix is dropped from pod and service names. On 5.9.0 and 5.9.1 the same services carry the ai-platform- prefix (for example, ai-platform-planner). If you have monitoring, alerts, or host overrides that use the prefixed names, update them when upgrading β€” see the 5.9.2 deployment guidelines. The ai-architect service is available only starting with 5.9.2 β€” it does not exist in 5.9.0 or 5.9.1 deployments.
The Designer AI chat surface routes through the ai-gateway service (part of the core services), which calls planner and the agent services. The evals-judge worker, deployed alongside the AI Platform, consumes ai.flowx.ai-platform.evals-judge.job.request.v1 for evaluations.

Per-service setup guides

Most AI Platform services deploy as subcharts with no standalone configuration and are covered by this guide. Services with their own operator-facing setup β€” external dependencies, secrets, storage, ports, or tunables β€” have a dedicated setup guide, grouped by the same deployment tiers as the deployment guidelines: All other AI services (embedder, knowledgebase-rag, knowledgebase-indexer-v2, planner, agent-builder, the config-time agents, data-privacy, doc-converter, evals-judge) are pure subcharts configured through this guide. flowx-docs (the in-product documentation host) also deploys as a subchart with no operator-facing configuration.

KB Enrichment

ai-platform-kb-enrichment (new in 5.9.1) replaces di-platform for design-time document intelligence. It deploys as a subchart but has extra requirements β€” a dedicated kbenrichment PostgreSQL database, an object-storage bucket, a Hugging Face model download on first start, doc-parser enabled, and an organization TEXT_GENERATION LLM capability. See the KB Enrichment setup guide for the full steps. The Qdrant collection knowledgebases_design is auto-created by the embedder service.

Environment variables

These variables control how services locate each other within the cluster:Kubernetes deployment:
Docker Compose / local deployment:

Agent Builder configuration


Kafka topics

The AI Platform uses the following internal Kafka topics:
For production environments, create these topics manually with appropriate replication factors. For development, Kafka auto-topic creation handles them automatically.

Deployment

The AI Platform ships as an umbrella Helm chart aggregating all microservices and infrastructure dependencies.Install or upgrade:
After deployment, initialize the platform:

Key Helm values

Replica counts:Global configuration:

Storage requirements


Troubleshooting

Kubernetes DNS resolution:
Common causes:
  • Incorrect GRPC_HOST_RESOLVER_HELM_CHART value
  • Services not in the same namespace
  • DNS not resolving due to CoreDNS issues
Qdrant health check:
Common causes:
  • Missing QDRANT_CONNECTION_API_KEY
  • Qdrant cluster not fully initialized
Verify broker availability:
Verify topics exist:
Common causes:
  • Wrong KAFKA_BOOTSTRAP_SERVERS address
  • Topics not auto-created and not manually provisioned
  • Security mode mismatch (KAFKA_SECURITY_MODE)
Verify Keycloak connectivity:
Common causes:
  • Incorrect SECURITY_OAUTH2_BASE_SERVER_URL
  • Realm name mismatch
  • Client ID not registered in Keycloak
  • SpiceDB token expired or misconfigured
If AI nodes fail with model-related errors:
  • Verify that an AI provider is configured at Organization Settings β†’ AI Settings β†’ Model Providers with a successful connection test
  • Check that models are enabled in the provider’s whitelist
  • Verify that workspace-type model assignments are set for the relevant AI capability (text generation, image understanding, embeddings, document/OCR) under AI Settings β†’ Defaults & Fallbacks
  • Ensure FLOWX_LIB_SECURITY_ORGANIZATION_MANAGER_BASE_URL is set on all Python AI services and points to a reachable Organization Manager instance
See the AI providers and model configuration page for setup details.

AI in FlowX

Overview of config-time and business AI agents

Agent Builder

Build custom AI agents with the no-code agent builder

Deployment guidelines v5.9.1

Component versions and upgrade instructions
Last modified on July 21, 2026