Engines Overview

TotalApp is powered by a set of purpose-built engines that separate business logic, data, AI orchestration, integrations, rendering, and observability into distinct, independently scalable layers. This page introduces every engine and how they work together end-to-end.

What Are the Engines?

Rather than one monolithic backend, TotalApp is built from a small number of specialised engines. Each engine owns one responsibility — data modeling, workflow execution, integrations, AI orchestration, UI rendering, or observability — so it can be reasoned about, scaled, and evolved independently. Engines are split into two groups: backend engines that run server-side and do the heavy lifting, and frontend engines that turn what the backend produces into the screens end users see.

                        TotalApp Engines
                        Matrix Agent — workflow / business-rule execution and AI-assisted scoring
Flow Engine — visual workflow graph runtime (nodes, edges, triggers)
Schema & Data Engine — turns no-code table definitions into a real, performant database schema
Integration & Webhook Engine — the gateway to the outside world (ingest + egress)
Agentic Routing Engine — orchestrates LLM calls, prompts, and AI agents
Event & Analytics Engine — collects logs, costs, and execution timelines from every other engine

                    

On the frontend, a lighter set of rendering engines takes whatever JSON schema the backend produces and turns it into a live, themed screen — without shipping a hardcoded page per feature.

Backend Engines

The backend engines are: Matrix Agent, Flow Engine, Schema & Data Engine, Integration Engine, Agentic Routing Engine, and Event & Analytics Engine.

Matrix Agent

The Matrix Agent evaluates, filters, and scores structured or freeform text data against configurable rules — must-have gates, weighted scoring criteria, and thresholds. It powers screens like Vendor Intelligence, Lead Scoring, and Compliance Radar, where a list of entities each needs a 0–100 fitness score plus an executive summary. See Compliance Radar and Vendor Matrix for concrete implementations.

Flow Engine

The Flow Engine is the runtime behind TotalApp's visual Workflow Editor — it executes graphs of nodes and edges, resolves per-node input/output contracts, and supports partial execution (running only the subgraph reachable from a trigger node). It is the same engine that drives inbound webhook triggers, scheduled triggers, and manual "Run Workflow" executions. See Workflow Editor.

Schema & Data Engine

This engine turns the visual tables a no-code user builds into a performant, safe database architecture behind the scenes. Users describe fields and relationships visually; the engine is responsible for translating that description into an efficient, tenant-scoped storage schema — without the user ever writing a migration by hand.

Integration & Webhook Engine

The gateway between TotalApp and the outside world. It manages both directions of traffic: ingest (inbound webhooks from Shopify, WooCommerce, Odoo, and other systems) and egress (outbound API calls TotalApp makes to those same systems).

Message Queue

A Redis / BullMQ-backed queue absorbs bursts of inbound traffic. When 500 webhooks arrive from Shopify at once, the engine immediately accepts them with an HTTP 200 and queues the payloads; the Matrix Agent (or Flow Engine) consumes them at a sustainable rate.

Idempotency

Every inbound event carries a request_id. If the same webhook is delivered twice because of a network retry, the engine recognizes the duplicate and processes it only once.

Exponential Backoff

Outbound API calls that fail are retried on an increasing schedule (e.g. 1 min, then 5 min, then 15 min) instead of hammering the downstream service immediately.

Agentic Routing Engine

The intelligent layer that optimizes AI calls, reduces token costs, and manages the traffic of Linter/Critic-style agent loops.

Provider Agnostic

LLM calls are abstracted behind a single interface. Application code never calls a specific provider (e.g. OpenAI or Anthropic) directly — it calls AgenticEngine.call(), and the engine resolves which model/provider actually handles the request.

Dynamic Prompt Injector

Combines retrieval results (from a vector database), system prompts, and tenant-specific rules into the final context sent to the LLM for each request.

Event & Analytics Engine

The observability center that collects the logs, token spend, and execution timings produced by every other engine and turns them into something a human can act on. See Event & Analytics Engine for the full breakdown of how it records events and estimates AI cost.

Time-Series Storage

A time-series database (e.g. ClickHouse / TimescaleDB) stores the high-volume stream of log events efficiently, enabling fast historical analysis.

Asynchronous Logging

Logging never blocks the main execution path. Events are emitted fire-and-forget (or via an event bus such as Kafka) so the Matrix Agent's own performance is never affected by observability overhead.

Cost Tracking

Produces per-tenant reports like "how many dollars of OpenAI/Claude tokens did this workflow consume this month?"

Visual Debugger

An interactive timeline shows exactly which step a workflow execution passed through, how many milliseconds each step took, and — if something failed — which agent or function threw the error.

Frontend Engines

On the frontend, TotalApp does not ship a hand-built page per feature. Instead, a small family of UI Rendering Engines read the JSON schema the backend produces and paint it onto the screen. This group includes the Dynamic Screen Renderer and the Theme Catalog.

UI / UX Rendering Engine — Server-Driven UI (SDUI)

Rather than hosting a fixed set of static pages in the React/Vite frontend, this engine interprets ("renders") JSON interface definitions sent from the backend to draw the screen. The same generic renderer produces very different screens depending purely on the schema it receives.

Semantic CSS & Theme Catalog

When the UI Engine reads a directive like "theme": "success" in an incoming schema, it automatically maps that semantic name to the platform's central Tailwind CSS catalog entry (for example bg-emerald-600 hover:bg-emerald-700 text-white rounded-lg) and applies it to the component. Because the mapping lives centrally in the Theme Catalog, switching a tenant's active theme instantly re-colors the entire platform — no per-screen changes required.

Dynamic Screen Renderer + Theme Catalog

The Dynamic Screen Renderer only ever draws what the backend schema tells it to draw — layout, fields, and actions. The Theme Catalog only ever supplies the skin (colors, gradients, blur) for the semantic names in that schema. Keeping these two concerns separate is what lets one renderer serve every screen in the app.

How the Engines Work Together

A single incoming event — for example, a new order created in Shopify — travels through all six backend engines before a human ever sees it, and then through the frontend rendering engines to become a screen:

1. Integration Engine → 2. Schema & Data Engine → 3. Agentic Routing Engine → 4. Matrix / Flow Engine → 5. UI Rendering Engine → 6. Event & Analytics Engine

Step	Engine	What happens
1	Integration & Webhook Engine	Captures the incoming Shopify order and places it on the queue.
2	Schema & Data Engine	Validates the schema of the table the order will be written to.
3	Agentic Routing Engine	Runs the order data through a Linter/Critic agent loop to analyze and clean it.
4	Matrix / Flow Engine	Applies business rules (if/else routing) to decide the order's approval path.
5	UI Rendering Engine	Draws the pending-approval order for the end user from the resulting schema.
6	Event & Analytics Engine	Reports the performance and AI cost of the entire journey.

Frequently Asked Questions

Is this a microservices architecture?

Not in the strict sense of separately deployed services. The engines are architectural layers within TotalApp's codebase, each with a single responsibility — this gives most of the reasoning and scaling benefits of microservices without the operational overhead of running many separate deployments.

Why does the Integration Engine need a queue instead of processing webhooks immediately?

External services like Shopify can burst hundreds of webhook deliveries in a very short window. Responding with HTTP 200 immediately and queuing the payload prevents timeouts on the sender's side and lets TotalApp process the backlog at a rate it can sustain.

Why is the Agentic Routing Engine "provider agnostic"?

Abstracting LLM calls behind one interface means TotalApp can change or add model providers without touching application code, and can route different request types to whichever model is most cost-effective for that task.

Does the Event & Analytics Engine slow down normal requests?

No. Logging is asynchronous (fire-and-forget or event-driven), so writing to the Event & Analytics Engine never blocks the request path of the engine that generated the event.

How do the frontend rendering engines relate to the backend engines?

The backend engines (especially Matrix Agent and Schema & Data Engine) produce a JSON description of what should appear on screen. The frontend's UI Rendering Engine (Dynamic Screen Renderer + Theme Catalog) is a pure consumer of that JSON — it never contains business logic itself, only rendering and theming logic.