BotForge

Architecture

How a message becomes a response

Every request on BotForge passes through the same layers, in the same order, whether it arrives on Telegram, WhatsApp, or your own website widget.

Client-facing

  1. 1

    Website

    The public, unauthenticated surface — marketing pages, documentation and this Developer Platform. Registry-driven, never hardcoded against product state.

  2. 2

    Dashboard

    The authenticated app shell. Sidebar sections and Centers activate per workspace based on which capabilities are installed and enabled — never a fixed menu.

    Read the docs

Tenant core

  1. 3

    Workspace

    The core tenant boundary. Every resource below this line — bots, customers, modules, workflows, analytics — is scoped by workspaceId. Organizations (Enterprise) aggregate many workspaces above it.

  2. 4

    Channels

    The messaging platforms themselves: Telegram, Discord, WhatsApp, Instagram, Messenger, Website Chat. Described in one place, the platform registry, so the UI never special-cases a platform by name.

    Read the docs
  3. 5

    Channel Adapters

    Each channel implements one ChannelAdapter interface — verifyWebhook, parseUpdate, send, setWebhook, validateToken, getIdentity — normalizing every platform's payloads into a shared NormalizedUpdate shape.

    Read the docs
  4. 6

    Bots

    One connected identity per platform connection. A workspace can run many bots across many channels — your Telegram bot can run a shop while your Discord bot runs support — each tracking its own health independently.

    Read the docs
  5. 7

    Modules

    Installable behaviour. The dispatcher routes every NormalizedUpdate to each ENABLED module for the receiving bot, in install order. Modules declare capabilities, permissions and workflow triggers/actions — the platform wires the rest.

    Read the docs

Platform services

  1. 8

    AI Runtime

    One orchestrator, runAgentTurn(), assembles the system prompt from an Agent's instructions plus knowledge-base retrieval, then runs a tool-calling loop through aiComplete() — the single chokepoint for provider fallback, policy and token budget.

    Read the docs
  2. 9

    CRM

    One customer profile per platform identity, merged into a single timeline. The Unified Inbox groups every conversation across every channel, with tags, notes, VIP flags and a full audit trail.

    Read the docs
  3. 10

    Workflow Engine

    A linear trigger → conditions → actions step list. Built-in triggers and actions merge at runtime with whatever a workspace's installed modules declare, so the builder palette is always accurate.

    Read the docs
  4. 11

    Analytics

    One real-time aggregation layer. Sections are gated by capability and permission, and every number is a real aggregate over workspace-scoped tables — never a fabricated metric.

    Read the docs
  5. 12

    Operations

    A registry-driven view of platform health. Incidents are derived from real signals — database, webhook delivery, queue depth, AI provider errors — never inferred or estimated.

    Read the docs
  6. 13

    Marketplace

    The install and publish pipeline for everything above: modules and AI assets (agents, prompts, knowledge packs, connectors, industry templates) share one submission, review and revenue-share system — never a parallel one.

    Read the docs
  7. 14

    Enterprise

    Optional governance layered above Workspace: Organizations aggregate Departments and workspaces, with SSO/SCIM identity, Enterprise RBAC and governed policies applied consistently across all of them.

    Read the docs