TotalApp Docs

Agents Overview

Rather than one monolithic backend, TotalApp is built from a number of specialised agents. Each agent owns one responsibility — data modeling, workflow execution, integrations, AI orchestration, UI rendering, or observability — so it can be reasoned about, scaled, and evolved independently. Agents are split into two groups: Core Agents that run server-side and do the heavy lifting, and Industry-Specific Agents that turn what the core produces into judgment calls for a given vertical.

What Is an Agent in TotalApp?

An agent is a backend unit that reasons over content and produces a judgment — a score, a classification, a risk assessment, a written analysis — rather than a fixed calculation. Where a TotalApp engine runs a deterministic algorithm the same way every time (a workflow graph, a database schema translation, a webhook delivery), an agent is given context and a goal, and is expected to interpret, weigh evidence, and explain its reasoning.

Agents sit alongside engines in TotalApp's backend, and the two categories are complementary rather than competing: engines move data and execute deterministic logic; agents make the judgment calls that logic alone cannot make.

In one sentence

Engines execute; agents reason. TotalApp uses both, and is standardizing on a modular pattern for adding new agents — especially industry-specific ones — without rebuilding shared infrastructure each time.

Core Agents vs. Industry Agents

TotalApp's agents fall into two broad categories:

Core Agents

Own the platform's core infrastructure — data modeling, orchestration, and workflow logic — and are usable by any module or add-on. Matrix Agent (rule-based scoring against configurable weights and gates) and Audit Agent (document/brand compliance review) are Core Agents in the sense that their pipeline, input contract, and output shape stay the same no matter which screen or industry calls them — only the rules and prompts change per screen.

Industry Agents (Industry-Specific Agents)

Turn what the core produces into a judgment shaped by one vertical add-on's specific operational reality — construction site execution, logistics dispatch, healthcare intake, and similar domain-specific workflows — where the reasoning, the tools it needs to call, and the approval flow around it are all shaped by that one industry's rules and terminology. Patent Agent is the first Industry Agent live on the platform.

Domain Execution Agents — the Target Architecture

TotalApp is standardizing on a modular, three-layer pattern for integrating Domain Execution Agents (Sektörel İcra Ajanları) into each vertical add-on. The goal is for every industry-specific agent — whether it's reviewing a construction permit, triaging a logistics exception, or flagging a compliance gap — to plug into the platform the same way, instead of every vertical inventing its own bespoke integration.

Direction of travel, not a shipped feature

The three-layer split described below is the architecture TotalApp's Domain Execution Agents are being designed toward. Today's sector add-ons call their agent logic directly rather than through this exact three-file separation — this section describes where the pattern is heading so new agent work can be built with it in mind from the start.

Each vertical's Domain Execution Agent is intended to split cleanly into three layers:

LayerPurpose
Expertise Prompt
prompt.md
The agent's domain expertise, written as a structured prompt rather than buried in application code — the vocabulary, the evaluation criteria, and the judgment style specific to that one industry (e.g. what "compliant" means for a construction permit vs. a customs declaration). Keeping this in its own file makes a domain expert's knowledge reviewable and versionable independently of the code that calls it.
Sector Tool/API Box
tools.ts
The specific tools and internal APIs that one vertical's agent is allowed to call — looking up a vendor record, checking a permit registry, querying a compliance rule set — scoped tightly to what that sector needs rather than exposing the platform's entire API surface to every agent.
Human-in-the-Loop Approval Screens
Approval screens
A reviewable, annotatable screen where a human confirms or overrides the agent's judgment before it becomes final — mirroring the same "AI proposes, human disposes" pattern already used by Audit Agent's findings reports. No Domain Execution Agent is intended to take a final action unsupervised.

Why split it this way

Separating expertise (prompt.md), capability (tools.ts), and oversight (approval screens) means a new vertical can be onboarded by writing its domain knowledge and its tool bindings, while reusing the same underlying agent runtime, job queue, and review-screen pattern every other sector agent already uses — rather than every add-on shipping its own one-off AI integration.

Frequently Asked Questions

What's the difference between an agent and an engine?
An engine executes the same deterministic logic every time it runs — a workflow graph, a schema translation, a webhook delivery. An agent is given context and reasons over it to produce a judgment — a score, a risk assessment, a classification — and that judgment can vary based on the specific evidence it's given, even under the same rules.
Are Domain Execution Agents available today?
The three-layer prompt.md / tools.ts / approval-screen split is the architecture TotalApp is standardizing on going forward, not something every vertical add-on already implements. The Core Agents (Matrix Agent, Audit Agent) and the platform's first Industry Agent (Patent Agent) are live today; further industry-specific agents built strictly to this three-layer pattern are the direction new Domain Execution Agent work is heading in.
Why keep domain expertise in a prompt file instead of code?
A prompt.md file can be read, reviewed, and updated by someone who understands the industry but not the codebase, and can be versioned independently of the surrounding application logic — the same way a business rule set is easier to audit when it isn't scattered across conditionals in a service file.
Do agents ever act without human approval?
The intended pattern is human-in-the-loop for anything consequential: the agent proposes a judgment, and a person reviews and confirms or overrides it on an approval screen before it becomes final — the same pattern Audit Agent already uses for its findings reports.
Where do I go to read about a specific agent?
See Matrix Agent for rule-based scoring, Audit Agent for document/brand compliance review, and Patent Agent for the IP & R&D reasoning endpoints. For the platform's deterministic engines (workflow execution, schema, integrations, rendering, observability), see Engines Overview.