← Docs

Questions

We run agents — what does this look like?

Tenant margin works today, whatever produced the request. Per-request attribution and the conservation invariant do not care whether a call came from a user typing or an agent looping.

The agent question is different: what does one RUN cost. An agent action is N inference calls plus M tool calls, and margin breaks because N is variable and occasionally enormous — a product can have a perfectly tame per-request cost profile and a catastrophic per-run tail. Answering that needs a column that groups calls belonging to one action. It does not have to be called run_id: trace_id, session_id, conversation_id or a parent-request reference all work, and you map it in step 2 exactly as you map the cost column.

If you have not got one, the audit says so up front rather than guessing. We will not infer run boundaries from timing. A guessed grouping is not a slightly fuzzy version of the right answer — its error concentrates in the tail, which is the only part of that chart anyone reads: long-running agents get split across windows and disappear from the expensive end, and concurrent agents for one tenant merge into a single run that never existed. No chart plus the name of the missing field beats a chart we cannot stand behind.

Two limits worth knowing before you start. Tool calls — search APIs, browsers, code sandboxes, retrieval — are real money and do not appear on a provider inference statement, so unless you declare those bills as sources, every figure describes inference spend only and understates total agent cost. And expect a large unattributed bucket: background agents, scheduled runs, evals and warm agents have no user and no tenant. That is honest rather than alarming, and it is reported as its own line rather than spread across the customers who happened to be active.

On pre-action limits — "was this agent allowed to spend this before it acted?" — the tower issues the clearance, the pilot flies the aircraft. NemulAI publishes a signed, versioned allowance per tenant and workload; your agent runtime reads it out of band, caches it, and enforces it locally with no per-call round trip to us. We record what the policy was and what was decided against it. We are never in your request path, and the decision record is still provable.

What if our usage data has no tenant ID?

Then per-customer margin is not available, and the audit says so in step 2 rather than at the end. The readiness check looks for a customer identifier that survives from the usage table through to billing; if it cannot find one, it tells you which tables would need to carry it.

Sometimes the id exists but under a name the mapper did not recognise — API key id, project id, workspace id. Step 2 shows every unmapped column so you can point at the right one yourself.

What if we self-host and there is no per-request cost anywhere?

This is the common case for anyone running their own GPUs, and it does not block the audit. Cost is derived from what you actually pay for the hardware — reserved instance, colocation invoice, or hourly rate — divided across the work those GPUs did in the period, using the usage table you already have.

Every figure produced that way is labelled with how it was attributed and how much uncertainty that carries. A number derived from a scheduler record is marked differently from one carried end to end by a request tag, and the report never presents the two as equivalent.

What happens to cost we cannot attribute to any customer?

It is reported as its own line, and it is not spread across your customers.

Splitting unattributable cost by revenue or by request count produces a per-customer number for every account and a different answer for at least one of them, with nothing in the data to support it. On the page it would look identical to a measured figure. So the audit shows the gap, states what it does to the period total, and names what would have to change in your schema for that cost to have an owner.

Can we run this without finance seeing it?

Yes. Steps 1 and 2 are anonymous and need no account. You paste schema metadata, and you get a readiness score and the exact SQL an audit would have you run. Nothing is stored unless you choose to save it, and nothing is sent to anyone.

That is deliberately the free half: you find out whether your data can answer the question before anyone else is involved.

What does NemulAI do with our uploaded CSVs afterward?

They are used to compute the audit and are subject to a retention window, after which the files are deleted and a deletion record is kept.

The derived figures outlive the files on purpose — a baseline you were shown has to stay reproducible after the source export is gone. What is retained is the result and the record of where it came from, not the rows.

Does NemulAI sit in our request path?

No. Nothing is installed, nothing proxies your traffic, and nothing routes, throttles, caps or reroutes anything. NemulAI measures inference it does not run.

If the economics move away from where a contract intended them to be, it says so and shows the evidence. What happens next is your decision, executed by your systems.

Still unanswered? kevin@nemulai.com