The Bottom Line
AI cost must be governed at the point where evidence becomes an action. Token prices and usage dashboards describe consumption, but they cannot show whether a route was permitted, an outcome succeeded, or a decision can be reproduced. LLM federated learning makes this gap harder to ignore because compute, data, tools, and authority may sit in different environments. The useful economic unit is cost per successful decision: the full cost of an authorised outcome whose evidence and execution path can be replayed.
Token prices do not measure decision cost
An autonomous system commits resources before a cost dashboard can explain them. It selects a model, assembles context, calls tools, moves data, and may trigger an external action. By the time token usage appears on a chart, the economically important choices have already occurred.
Inference price still matters. It simply answers a narrow question: what did the model consume? It does not establish whether the request served a valid objective, whether the evidence was current and permitted, or whether the action worked. A cheap call that starts an invalid action can cost more to recover from than an expensive call that resolves the matter correctly.
Human supervision often conceals this gap during experimentation. A person removes irrelevant context, rejects a weak answer, retries a request, or stops an unsafe tool call. Once agents act without that continuous intervention, the hidden corrections become system costs:
- context retrieval that brings no decision value
- model calls repeated after avoidable failures
- duplicate tool actions caused by uncertain delivery
- approvals requested after authority should have been checked
- data transfer that a local execution path could have avoided
- investigation and recovery after an incorrect action
A recent Databricks discussion defines AI cost management as measuring, attributing, controlling, and optimising spend for business value. It also argues for choosing the lowest-cost model or agent harness capable of meeting the required quality. That is a useful market signal. Yet value cannot be attributed reliably when the request record ends at prompts, tokens, and tool traces.
The economic progression is clearer when the units are compared.
The last measure does not replace token accounting. It gives token accounting operational meaning.
Cost governance belongs at the decision boundary
A decision boundary is the control point where evidence, policy, model selection, tool authority, and budget resolve into an allowed action. Governing that boundary means rejecting ineligible routes before they spend money or change external state.
A central gateway can collect consistent usage data. It may also enforce provider budgets and model access. Those are useful controls, but the gateway sees only what passes through it. Local retrieval, data transfer, tool side effects, approval state, and recovery work may belong to other systems.
Central visibility is therefore not the same as complete control.
The route should be chosen from eligible execution paths, not from every technically available model. Eligibility must be established first. Cost optimisation comes second. A policy might express the order like this:
decision_policy:
objective: "classify-and-escalate"
quality_floor: 0.94
max_latency_ms: 800
allowed_data_regions:
- eu-west
- on-prem-secure
allowed_models:
- local-small-v3
- local-medium-v2
- approved-frontier-eu
tool_authority:
- "read:case-events"
- "write:escalation-queue"
approval_required_if:
- "risk_score >= 0.80"
budget:
max_cost_usd: 0.18
This is an illustrative policy, not a measured deployment configuration. Its purpose is to make the optimisation order explicit. A route outside an allowed region is not cheap. It is ineligible. A model below the quality floor is not efficient. It fails the decision requirement. A tool without write authority is unavailable, regardless of latency.
This framing also changes AI model routing. A conventional router maps a request to a model using predicted quality, speed, and price. A governed router evaluates the whole execution plan: evidence location, model, context, tools, policy, approval, and expected recovery path. The model is one component of the route.
The result should be durable. Otherwise, the policy is enforced in one system while evidence and outcome are recorded elsewhere. That separation makes both cost attribution and later challenge harder.
This is the difference between spend reporting and autonomous AI cost control. The first explains consumption. The second constrains an action before cost and authority separate. Related Scalytics essays on this boundary: Decision Fabric Is the Missing Boundary in Accountable AI and When Does Persistent Agent Memory Become Accountable?.
Can federated AI be cheaper without centralising data?
Yes, federated AI can be cheaper without centralising data, but only when the saved movement and exposure costs exceed the added coordination and local operating costs. Federation changes the cost function. It does not guarantee a lower bill.
The phrase LLM federated learning often collapses three different patterns. Federated fine-tuning sends model updates rather than raw training data. Federated inference runs model execution across controlled locations. In-situ processing brings computation to data that remains under local control. Each pattern affects cost differently.
Local execution may avoid repeated transfer, central duplication, and disclosure to an external processing environment. It can also use existing compute near the evidence. Those savings must be weighed against model distribution, local capacity, scheduling, telemetry, version management, and failure recovery.
A useful comparison concerns complete paths, not hosting labels.
Central execution can remain the lowest-cost eligible option when data is small, movable, and already near shared compute. Local execution can win when movement is large, disclosure is restricted, or timely evidence exists only at the source. Hybrid routing is often the honest answer, but it needs a ledger that makes unlike paths comparable.
Routes must compare complete execution paths
The cheapest eligible route is the route with the lowest expected total cost after quality, latency, locality, risk, tool authority, and approval constraints have been applied. That statement sounds simple. Building the estimate is not.
A route cost should include at least:
- inference and local compute
- context retrieval and data transfer
- tool execution and external service charges
- coordination, queueing, and approval delay
- expected retries and failure recovery
- durable telemetry and replay storage
- the expected cost of an incorrect or unauthorised action\
The final item cannot always be reduced to a precise currency value. A policy can still classify it by consequence and exclude routes above an accepted threshold. False precision would make the calculation look stronger while weakening the decision.
Recent academic work gives model assignment a firmer basis. A 2026 arXiv preprint on UniMASO (joint prompt and model optimisation for heterogeneous multi-agent systems) evaluates configurations across five benchmarks and five execution topologies. Under its centralised execution comparison, the reported average score increased from 69.79 to 70.40 while token-weighted deployment cost fell by 85.2% relative to DeepSeek-V4-Pro with MASPO.
That result matters because it treats model assignment as part of workload design. Different agent roles may warrant different models. A fixed choice of the strongest model can therefore be economically inferior to role-specific assignment.
But UniMASO does not establish total operational cost for an autonomous production system. Its reported cost is token-weighted deployment cost within the experimental design. It does not price jurisdictional restrictions, data movement, local hosting, approvals, tool side effects, observability, or recovery after an incorrect action. Research evidence supports heterogeneous assignment. It does not remove the need for a decision ledger.
This distinction prevents a common category error. A routing benchmark compares candidate inference arrangements. A decision-cost system compares executable and authorised operational paths.
The ledger must connect spend to authority and outcome
An AI decision record is a durable account of the objective, evidence, execution route, policy authority, cost, result, and replay reference for one operational decision. Its fields should be captured as the decision proceeds, not reconstructed from disconnected logs later. Consistent AI decision records make routes comparable across locations without forcing every event into one platform.
The record below is illustrative. The values are examples, not measured results.
{
"decision_id": "dec-01J...",
"objective": "classify-and-escalate",
"evidence": [
{
"event_id": "case-event-8841",
"topic": "case.events.v1",
"observed_at": "2026-10-26T06:41:12Z",
"location": "eu-west",
"freshness_seconds": 7
}
],
"execution": {
"model": "local-medium-v2",
"tools": ["case.read", "escalation.write"],
"data_location": "eu-west",
"route_reason": "quality_floor_met_under_region_policy"
},
"policy": {
"policy_id": "case-escalation-v4",
"result": "approved",
"authority": "local-policy-engine",
"approval_required": false
},
"economics": {
"input_tokens": 1840,
"output_tokens": 212,
"compute_cost_usd": 0.04,
"tool_cost_usd": 0.01,
"transfer_cost_usd": 0.00,
"total_cost_usd": 0.05
},
"result": {
"action": "escalate",
"outcome": "accepted",
"quality_score": 0.96,
"latency_ms": 612
},
"replay": {
"event_offset": 8841,
"policy_version": "case-escalation-v4",
"model_version": "local-medium-v2"
}
}
The structure resolves questions that a usage line item cannot answer. Which evidence supported the action? Was it fresh enough? Which policy authorised the tools? Why was that model selected? Did the result succeed? Can the same evidence, policy, and model version be examined again?
Durability matters here. Source events, policy evaluations, route choices, tool actions, outcomes, and replay metadata need stable identifiers and ordering. Kafka can carry those typed event flows across controlled environments. An object store or another retained event layer can preserve longer history. The architecture must also handle idempotency, backpressure, and duplicate delivery because each can change the real cost of a decision. For agent observability cost specifically, see Open-Source Kafka Observability for AI Agents.
A Sovereign Decision Fabric is an operator-controlled architecture that keeps event evidence, policy-bound reasoning, action records, and replayable outcomes connected across execution environments. The term is useful only if the record is testable. A category claim without a complete decision record remains positioning.
The ledger also sets a boundary around MCP. A scoped MCP tool can reduce unnecessary context and expose a controlled capability. It does not, by itself, prove why the model was allowed to call that tool, what the full route cost, whether the action succeeded, or how the decision can be replayed. See Why Kafka and MCP Are Not Enough for Autonomous AI Agents.
Centralisation hides part of the bill
Centralised ontology platforms and export-into-the-lake architectures simplify some forms of analysis by bringing data and control into one place. Their weakness appears when the movement separates evidence, authority, spend, and outcome from the action boundary.
A copied record may be stale when an agent acts. An ontology can describe relationships without proving that a specific policy authorised a specific action. A central usage dashboard can aggregate spend while missing local compute, transfer, approvals, and recovery. Retrieval can provide relevant context without granting authority to change external state.
None of these systems is useless. The issue is architectural scope.
A decision record should remain complete even when its components are distributed. Logical consistency does not require physical centralisation. Shared schema, stable identifiers, policy versions, signed authority, and ordered events can provide a common control model while data and execution remain in approved locations.
This approach also fits established risk reasoning. The NIST AI Risk Management Framework is voluntary and frames trustworthy AI as a concern across design, development, use, and evaluation. A route record supports that lifecycle view because it ties an operational outcome to the model, policy, evidence, and controls in effect at the time. It does not prove that every risk has been managed. It makes a concrete decision available for evaluation.
European policy now gives lifecycle controls added operational weight. The European Commission has published EN 18286:2026, a quality management system standard for EU AI Act regulatory purposes. Providers of high-risk AI systems who implement it can benefit from a presumption of conformity with the Article 17 quality management system requirements covered by the standard. The standard does not mandate a Kafka schema or a decision fabric. Its lifecycle orientation does strengthen the case for versioned routes, monitored operation, corrective action, and evidence that survives after execution.
Post-hoc reports can summarise those activities. They cannot recreate missing provenance.
Governance has a price worth making explicit
Decision-boundary control adds work and cost. Any argument that omits those costs cannot support a credible route choice.
The added costs include schema design, policy evaluation, model testing, telemetry, retained replay data, and failure handling. Federated execution adds capacity planning, software distribution, policy consistency, and observability across locations. Local models need version control and evaluation before a router may treat them as eligible. Event retention can also grow without discipline.
Latency is another limit. A policy check, remote approval, or cross-location planner can delay action. High-frequency or safety-sensitive decisions may need pre-authorised local policies and bounded fallback behaviour. Some tasks will still justify a frontier model because the expected cost of a poor result exceeds the model premium. Others should remain central because the data is already there and federation adds no useful control.
Outcome valuation is difficult too. Some results have direct financial values. Others are better expressed as service restoration, avoided disclosure, correct classification, or compliance with a decision rule. Cost per successful decision remains useful if "successful" is defined before routing and tested after action. It becomes misleading when success is invented to fit available telemetry.
A disciplined rollout can stay narrow:
- Select one repeatable decision class.
- Define success, failure, and prohibited outcomes.
- Specify the evidence and authority required to act.
- Record model, tool, policy, transfer, and compute costs.
- Permit routing only among evaluated, eligible paths.
- Add a federated alternative where locality changes the economics.
- Compare cost per successful, authorised, replayable decision.
- Replay failures and revise the policy or route model.
The final test is deliberately demanding. For one action, can the system show which evidence was used, which route was considered, why the chosen model and tools were allowed, what the complete path cost, whether the outcome succeeded, and how the decision can be replayed?
If the answer is no, the system does not yet control autonomous AI cost. It reports consumption. The position worth defending is whether that distinction should remain optional once software has authority to act.
Lascaris is our platform for governed AI agents on the Kafka you already run. It keeps the decision record next to the event evidence, so cost, authority, and outcome stay connected when an agent acts.
Sources
- Databricks, AI Cost Management: https://www.databricks.com/blog/ai-cost-management
- Cai et al., UniMASO arXiv preprint 2610.31743 (2026): https://arxiv.org/abs/2610.31743
- NIST, AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
- European Commission, First harmonised standard supporting the AI Act (EN 18286:2026): https://digital-strategy.ec.europa.eu/en/library/first-harmonised-standard-supporting-ai-act-published-official-journal
- European Commission AI Act Service Desk, Article 17: Quality management system: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-17
