AI Governance
Required Access Level
Super Admin
The AI Governance Dashboard is an exclusive tool for the Super Administrator of the Flowi Agentic platform. Its primary goal is to provide transparency and control over the financial consumption of Artificial Intelligence across the entire infrastructure.
Someone who administers a single tenant does not reach this screen: typing the address takes them back to the Dashboard.
Note
Flowi Agentic is designed on a Single-Client, Multi-Tenant architecture. This means the parent organization pays the Artificial Intelligence API bills (e.g., OpenAI, Google Gemini), and the governance dashboard serves to allocate, audit, and control the costs of each isolated department or client (Tenants).
The Quota System
To ensure that the AI bill does not spiral out of control, the system implements two levels of barriers:
1. Tenant Quota (Level 1)
Each Tenant receives a maximum limit of monthly tokens (or by configured period). When this limit is reached, the Tenant is immediately blocked from performing interactive operations with AI (such as chatting with agents or generating forms via AI).
Every Tenant is born with a quota of 1 million tokens, created along with it. Adjust the value under Tenants → (the tenant) → AI Token Quota.
A tenant with no quota gets no AI at all
The barrier is the quota existing, not only its value. A Tenant with no quota row is refused before its first call, with the same message as one that ran out. If an agent answers that no quota is configured, this is it — open the screen above and save.
2. User Quota (Level 2)
Within a Tenant, sub-limits can be defined for specific users, which prevents a single employee from consuming the entire monthly budget allocated to the whole department. Today it is the Super Admin who writes that sub-limit — the route that saves it (PUT /api/admin/users/{id}/ai-quota) requires that role, and a tenant Admin cannot reach it.
What counts towards a person's sub-limit. Besides what they spend on the on-screen copilots, it also counts what the AI steps they started spend — whoever starts a process or a case answers for the tokens that run burns. The person's counter goes up; the process does not stop when the sub-limit runs out, because an AI step is a Soft Limit (see the next section). What the sub-limit blocks is still only what is a Hard Limit: the copilots.
A step with nobody behind it has no owner, and that is deliberate. A step reached by a timer, started through an API key, or redone by the platform after a node died has no user — the spend goes to the Tenant's account and shows up with no person in the report. Attributing it to someone there would be inventing a responsible party.
Soft Limits vs Hard Limits
- Hard Limit (Automatic Blocking): Actions triggered manually by humans (interactions in the Copilot) are strictly blocked if the quota runs out.
- Soft Limit (Overage): Scheduled or ongoing actions executed invisibly by the system (robots,
Java Delegates, or background automations) are not interrupted when the quota runs out. This prevents vital company processes from failing halfway. Tokens spent beyond the limit enter the database as Overage Tokens, to be settled later.
AI BPMN validation is a Hard Limit, and only the tenant admin triggers it
The modeler's semantic validation button calls the model and spends the tenant's quota like any copilot. That is why the route (POST /a/ai-validation/bpmn) requires a tenant Admin or Super Admin — manager and ordinary user get 403. With no quota left, the call is refused with 402 and the message names the tenant; it does not come back disguised as an opinion about the diagram. If someone reports that validation "could not finish the analysis", that is a provider failure, not the quota.
A call that produces no answer is billed too
An agent can call the model and get an empty response — the provider refuses, or finishes without writing anything. The input tokens were billed anyway, because the prompt was processed. The platform records those calls and charges them to the tenant's quota, so that the dashboard's number does not sit below what the provider invoices.
In the audit list this shows up as consumption with no matching result. A tenant with high usage and few completed processes should be checked for barren calls first.
When the platform cannot count, the copilot refuses
Copilots answer as a stream, and the provider reports the token count only in the closing chunks of the response. If that count never arrives, the platform does not deliver the answer in the copilots or the playground: without a count there is no way to debit the quota, and a ceiling that never closes is not a ceiling. The user gets a message saying exactly that, and the call is recorded in the audit list with a zero count and the origin resposta-sem-contagem-de-tokens — its real spend is greater than zero.
For processes the decision is the opposite, for the usual reason: the step delivers its result and the gap is recorded. Stopping a process over a hole in a report would trade an accounting problem for a production outage.
If that warning shows up often, the provider configured under Administration → AI Models is the first place to look.
The same holds for a step that ends in a blocking issue raised by the agent: the model read the document, concluded the work cannot be done and ended the step with a code. The step fails, nothing is written to the result variable — and the call is counted and debited like any other, because the provider charged for it. What the screen does not show is the blocking-issue code: that failure list is read through the API today, not from here.
A call cut short: billed by the provider, not measured here
There is a case where the platform knows it spent and does not know how much. When one of the agent's tools fails mid-conversation — database down, storage unavailable — the call is aborted. The prompt was already sent and the provider already charged for it, but the response that carries the token count never arrives, and there is nowhere to get the number from.
These calls appear in the report with zero tokens and no output produced. The zero is not the real consumption: it is the mark of consumption that could not be measured. We prefer the row with a zero to no row at all, because an invisible gap does not get investigated.
What this means for reconciliation
If the provider's invoice comes in above what the dashboard adds up, the zero-token calls are the first place to look. The more tool failures a tenant had in the period, the larger the difference.
A refused quota is a different case and produces no record: the check happens before anything is sent, so nothing was transmitted and nothing was charged.
The token charge is not undone if the process fails afterwards
The quota is debited in a transaction of its own, separate from the transaction of the process that made the call. In practice: if the task fails after the AI answered, the tokens stay debited.
That is the correct behaviour, and it is worth saying why. The provider charged the moment it answered — the spend happened, whatever became of the process next. If the debit were rolled back along with the task, the dashboard would show less consumption than the invoice, precisely in the tenants that fail most.
That separation is also what allows several documents to be processed at once: the tenant's quota row is locked only for the instant of the debit. Were it locked for the whole AI call — some twenty seconds — every other call from the same tenant would queue behind it, one at a time, no matter how many threads were available.
How many AI steps run at once
AI steps wait for the provider on a pool of their own, separate from the process engine's job queue — while the model thinks, the step occupies no execution slot and no database connection. How many run at once is AI_STEP_CORE_SIZE, which is 8 by default.
The ceiling is per installation, not per tenant: the same pool serves both engines, so the slots are shared by every tenant, process steps and case steps alike. Past the slots, steps wait in a queue of 100 (AI_STEP_QUEUE_CAPACITY); past the queue, a step is closed as a failure and made available for reprocessing rather than stopping in silence.
Where the throughput number comes from
The arithmetic is concurrent steps × 60 ÷ call latency in seconds. With the 8 default slots and a call of roughly 20 s, that is about 24 steps per minute for the whole installation.
This is arithmetic, not a measurement of your installation. The bench that produced the published numbers ran against the previous, 2-slot design, in a test where the model call is an artificial wait of a fixed duration: no provider is contacted, and the database and RAG are out of the path. The ~20 s latency itself does come from a real observation, but from a single fiscal-document workload, on 2026-08-12.
Treat the number as an order of magnitude for sizing, never as contracted capacity: real throughput depends on the model, the size of the prompt and whatever else the installation is running. Measure with your own load before promising anyone a number.
The Dashboard
The ceiling is not the tenant's spend
The value you configure is the Copilot Ceiling — it only stops the assisted screens. Processes keep running once the ceiling is reached, and whatever goes past it lands as Process Overage. A tenant's real consumption is therefore used + overage, and that is the number the screens call Total Consumption. Reading the ceiling as if it were the total leads to the wrong conclusion that process work is free.
The panel shows three global metrics at the top:
- Global Usage This Month (Tokens): sum of AI tokens in the period.
- Total Consumption (Copilots + Processes): what the platform actually spent across all tenants, with Process Overage right below it, kept separate.
- Tenants With Copilots Blocked: how many hit the ceiling — with the count of active tenants in the caption. Blocked here means copilots stopped, never processes stopped.
Below it comes the audit list, one row per tenant with three numeric columns: Total Consumption (used + overage), Copilot Ceiling and Process Overage.
Resetting quotas
The available actions are:
- Copilot Ceiling (Max Tokens): under Tenants → (the tenant) → AI Token Quota, raises or lowers the ceiling for the assisted screens. It does not cap processes.
- Force Reset: manually zeroes the tenant's counters — used and overage tokens go back to 0 (used for billing corrections or courtesy extensions) and the cycle restarts.
The same reading applies on the user screen (Users → (the user) → AI Quota per Tenant): the number configured there is that person's copilot ceiling, not a cap on what processes may spend on their behalf.
Consumption by process step
Below the tenant list, in the same panel, sits the Consumption by process step table covering the last 30 days. It exists because a token count alone does not say what to change: knowing that a step spent 41,000 tokens does not separate expensive model from bloated prompt from agent stuck in a loop, and those call for opposite fixes.
Each row is a step, most expensive first. A step here is either a task of a process or an AI step inside a case — the Feature column tells them apart, AI_DELEGATE for a process and AI_CASE_DELEGATE for a case. Notice that before looking the row's key up in the process catalog: on a case row it is the case key.
Beside calls, tokens and cost, three columns explain the spend:
- Iterations — how many round trips to the model a single execution of that step took on average. A high number means the prompt or the tool descriptions are not getting the model where it needs to go. Moving to a cheaper model does not fix that. A step the engine retried does not inflate this number: the retries of one step stay one execution, and what separates them is the attempt number recorded on each call.
- Context — how much of the prompt is context retrieved from the knowledge base. A high percentage points the cost at retrieval rather than the model: retrieve less, or retrieve better.
- Wasted — the share of tokens spent on calls that produced no answer. This is the first place to look, before touching any prompt.
Rows crossing an attention threshold are highlighted with an icon. The rest stay neutral on purpose: a table where every row shouts communicates nothing.
When the cost is incomplete
A warning icon next to the cost means some call in that step used a model with no price registered. The cost shown is partial. Without the warning the step would look cheap precisely because information is missing, which is the opposite of what the number should say.
Unattributed consumption
An unattributed warning means calls reached the model without declaring which feature they came from. The tokens are real and were charged; what is missing is the origin tag, which is recorded in the application log. It is an instrumentation gap to report, not a billing error.
Embeddings show up here too
Embeddings generated by knowledge-base ingestion and by RAG retrieval are measured and show up as a RAG_EMBEDDING group in the table, with no process or step attached — an embedding does not run inside a flow step. The price comes from the global embedding configuration, in the Vector Database (RAG) tab of the AI Configuration screen — not the chat model catalog: an embedding has no completion tokens, so the cost is computed on prompt tokens alone.