Architecture

This page is intentionally short and stable. It explains the architecture boundaries so platform teams, DSI, RSSI, and run teams can align quickly.

For implementation details and fast-moving parameters, rely on the GitHub references listed at the end.

System Overview

flowchart TD
    UI["User Interface (React)"]
    Keycloak["Keycloak / OIDC"]
    Agentic["Agentic backend (FastAPI)"]
    Runtime["Agent runtime (ReAct / Graph)"]
    Policies["Governance policies\nmodels · tools/MCP · prompts · agents · data"]
    Routing["Model routing resolver"]
    LLM["LLM providers\nOpenAI / Azure / Ollama / ..."]
    Tools["Tool layer\nbuiltin + MCP + custom"]
    KF["Knowledge Flow backend"]
    Temporal["Temporal server"]
    Workers["Temporal workers"]
    Stores["PostgreSQL / ClickHouse / object storage"]

    UI -->|"Bearer token"| Agentic
    UI -->|"Login"| Keycloak
    Agentic -->|"JWT validation"| Keycloak
    Agentic --> Runtime
    Runtime --> Policies
    Runtime --> Routing
    Routing --> LLM
    Runtime --> Tools
    Tools --> KF
    KF --> Temporal
    Temporal --> Workers
    Agentic --> Stores
    KF --> Stores

    classDef core fill:#f5f7ff,stroke:#333,stroke-width:2px;
    class Agentic,Runtime,Policies,Routing core;

    classDef external fill:#f4f4f4,stroke:#999;
    class UI,Keycloak,LLM,Temporal,Workers external;

Core Flows

Conversation flow

  1. User authenticates through OIDC.
  2. UI calls Agentic backend (REST + WebSocket).
  3. Runtime executes agent logic (ReAct or Graph).
  4. Governance and routing policies select effective model/tool behavior.
  5. Output and traces are persisted according to deployment settings.

Processing flow

  • Knowledge Flow processing is executed through Temporal workflows.
  • Workflows run in one or several workers depending on target scale.
  • This gives durable execution, retries, and operational observability.

Current Release Positioning

  • Temporal is now a first-class processing backbone in Knowledge Flow.
  • ClickHouse can be integrated as a store option (notably for data-heavy/vector/config profiles depending on platform design).
  • Governance remains policy-first across models, tools/MCP, prompts, agents, and data.

Why This Architecture

  • Decouples interaction runtime from long-running processing.
  • Supports enterprise governance and auditable behavior.
  • Enables customer fork operation models without hardcoding deployment assumptions.

Source Of Truth (GitHub)