What Is IoA Usage Accounting? The Beginner's Guide to Auditable Agent Billing Across Domains
CodexFuse Team · 2026-11-05T20:35:04.115Z · 21 min read min read
What Is IoA Usage Accounting? The Beginner's Guide to Auditable Agent Billing Across Domains
What Is IoA Usage Accounting?
What is IoA usage accounting? It is a proposed framework for recording, checking, and reconciling the work that AI agents do when they collaborate across different organizations and domains. The letters IoA stand for Internet of Agents, not Inter-Office Account from corporate finance and not Input-Output Analysis from life-cycle assessment, two unrelated meanings that share the same acronym.
The framework is defined in an IETF Internet-Draft called Verifiable Usage Accounting for Internet of Agents, published as draft-zhang-ioa-usage-accounting-01 on November 2, 2026.
The draft gives every domain the same vocabulary for five things: the scope of a task, the rules for measuring it, the quantities being measured, the records of what happened, and the evidence that backs those records up. With that shared vocabulary, a platform that ran part of a job and a platform that ran the rest can compare notes, correct mistakes, and settle disputes without trusting each other's private logs. The goal of Internet of Agents accounting is auditable agent billing across domains, built on records any receiver can check against declared rules.
The draft comes from five authors at AsiaInfo Technologies in Beijing, and it is an individual submission rather than a product of an IETF working group. It is an Internet-Draft, which means it is work in progress and not an adopted standard, its intended status is Informational, and it expires on May 6, 2027 unless a newer revision replaces it. That status matters, because everything in this guide describes a proposal, not a rule that any system must follow today.
The records this framework produces need tamper-evidence, and the same hash ideas behind a SHA-256 hash generator show up in the evidence layer described later in this guide. If you run agents on rented infrastructure, the accounting problem also starts with the bill for the machine underneath, which is why this guide sits beside our explanation of VPS hosting.
Why App Logs and Platform Billing Cannot Do This Job
One agent can now start a task, hand part of it to a second agent on another platform, and receive results from a third. Each platform keeps its own logs, counts usage in its own units, and bills through its own system. When the customer asks what the whole job cost, or why two invoices disagree, nobody has a single record that covers the full chain.
App logs are written for debugging, not for accounting. They record what a developer needed at the time, in whatever format the application chose, and they are easy to edit after the fact. A billing API is the opposite problem: it reports a total, but it hides the events, the measurement rules, and the evidence behind that total.
Cross-domain accounting needs a third kind of record, one that is structured, comparable, and checkable by a receiver who was not there when the work happened. That is the gap the draft tries to fill, and it is the same gap that agent frameworks are trying to close from the other side. Readers who want the framework view can start with What the I2ICF framework is, while the security side of the same problem is covered by What the Agentic AI Security Framework is.
An agent usage accounting framework that tried to do everything would do nothing well, so the draft's answer is deliberately narrow. It does not build a billing product, and it does not tell anyone what to charge. It defines the records and the evidence, and it leaves pricing and payment to other systems, a boundary the later sections of this guide return to.
The Five Building Blocks at a Glance
The draft's object model has five pieces, and they chain together in one direction. An Accounting Context sets the scope, a Metering Profile declares how usage inside that scope is measured, Measurement Dimensions name what is counted, Usage Event Records capture what happened, and Accounting Evidence References point at the proof. Together they form the agent usage accounting framework the draft proposes, and the table below summarizes each piece before the following sections explain them one by one.
| Piece | What it is | What it answers |
|---|---|---|
| Accounting Context | The scope that binds identifiers, policies, and evidence rules for one task or session | Which job does this record belong to? |
| Metering Profile | The declared rules for how usage is measured and what evidence is required | How was this usage counted? |
| Measurement Dimension | One quantity, its unit, and how its value was obtained | What was measured, and in what unit? |
| Usage Event Record | The structured record of one observed accounting-relevant event | What happened, when, and where? |
| Accounting Evidence Reference | A pointer to the integrity-protected evidence behind a record | What proves this record? |
Two details matter before the detail sections. First, every piece is a declaration or a record, not a service: nothing in the draft runs a server or moves money. Second, the pieces are designed so that a receiver in a different domain can interpret a record without access to the sender's internal systems, which is the whole of verifiable usage accounting Internet of Agents as the draft defines it.
Accounting Context: The Scope That Holds a Task Together
An Accounting Context is the scope inside which Usage Event Records are correlated and interpreted. It binds together the identifiers, policies, metering profiles, and evidence requirements for one task, invocation, session, or gateway-mediated collaboration. Without it, a usage record is just a number with no statement of what job it belongs to.
A context should carry its own identifier, the accounting domain it belongs to, the gateway and agent involved, the task, session, invocation, and trace identifiers, a subject reference, a policy reference, a metering-profile reference, an evidence policy, a validity window, and a privacy scope. It must be unambiguous inside the domain that asserts it, and when it crosses into another domain, the receiver must be able to identify who asserted it, how long it is valid, and what disclosure constraints apply.
| Context field | Purpose |
|---|---|
| accounting-context-id | Identifies this scope within its domain |
| accounting-domain-id | Names the administrative domain responsible for the records |
| gateway-id | Names the gateway that mediated the collaboration |
| agent-id / agent-did | Names the agent that performed the work |
| task / session / invocation / trace ids | Tie the record to one specific job and its execution trail |
| subject-ref | Names the subject the work was done for |
| policy-ref | Points at the policy that governs this scope |
| metering-profile-ref | Points at the measurement rules in force |
| evidence-policy | States what evidence must be kept and for how long |
| validity | Gives the start and expiry of the scope |
| privacy-scope | States what may be disclosed outside the domain |
The practical effect is that two domains can talk about the same job without sharing the same database. Each side keeps its own records, and the context identifier is the thread that ties them together when a dispute or a reconciliation needs to pull the chain apart.
Metering Profile: The Rules for How Usage Is Measured
A Metering Profile declares how usage is measured and what evidence is required, for one capability, agent, gateway, or accounting domain. It is the rulebook that a context points at: the categories of usage it supports, the dimensions it measures, the methods it requires, and the evidence it demands. Two records measured under different profiles are not automatically comparable, which is why a record used for cross-domain reconciliation must name the profile and its version.
A profile should specify its identifier and version, the usage categories and measurement dimensions it supports, the measurement methods it requires, the evidence types it requires, and how it aggregates, corrects, and exports records. It should also state its privacy behavior, covering redaction, pseudonymization, minimization, and selective disclosure, and its export behavior, covering push, pull, batch, streaming, or local-only handling.
| Profile declares | Why it matters |
|---|---|
| Profile id and version | Lets a receiver know exactly which rules produced a record |
| Supported usage categories | States what kinds of work this profile covers |
| Supported measurement dimensions | States what quantities can be reported |
| Required measurement methods | States how each value must be obtained |
| Required evidence types | States what proof must accompany a record |
| Aggregation behavior | States whether records roll up per event, per task, per session, per window, or as summaries only |
| Correction behavior | States how wrong records are fixed without rewriting history |
| Privacy behavior | States how personal or sensitive data is redacted or minimized |
| Export behavior | States how records leave the domain: push, pull, batch, streaming, or local-only |
The profile is where the draft's honesty lives. By forcing the measurement rules into the open, it makes it possible for a receiver to ask whether a number was observed, reported by a provider, estimated, sampled, or derived, instead of taking a bare total on trust.
Measurement Dimensions: What Gets Counted, and in What Unit
A Measurement Dimension declares what is measured, which unit is used, which usage category or modality it applies to, and how the value is obtained and aggregated. The draft names example dimensions such as input-token-count, output-token-count, cached-token-count, reasoning-token-count, processing-time-ms, request-count, transferred-bytes, tool-call-count, workflow-step-count, delegation-count, and standard-compute-usage. Each dimension carries a unit, a value type, a measurement method, an aggregation scope, and a privacy class.
Dimension labels do not establish comparability on their own. Token counts must identify the model, the tokenizer, or the provider counting convention behind them, and a cached or reasoning subset must not be added again to a total that already includes it. The draft also treats a Standard Compute Unit, or SCU, as a normalized unit for compute across heterogeneous models and tools, but it defines no calibration, exchange rate, or pricing for an SCU, so no SCU price or conversion can be quoted from this draft.
One distinction runs through the whole draft and is worth stating plainly. A measured zero is a value, and it is not a default for a measurement that is unavailable, withheld under policy, or not applicable. Reporting a dimension as zero when it was never measured would hide a gap in observation, and the draft requires explicit coverage limitations instead.
| Dimension | Unit | What it counts |
|---|---|---|
| input-token-count | token | Tokens sent into a model call |
| output-token-count | token | Tokens produced by a model call |
| cached-token-count | token | Input tokens served from cache |
| reasoning-token-count | token | Tokens spent on reasoning before the answer |
| processing-time-ms | millisecond | Time spent processing a request |
| request-count | request | Requests made to a capability |
| transferred-bytes | byte | Data moved between domains |
| tool-call-count | operation | Tool invocations performed |
| workflow-step-count | step | Steps completed in a workflow |
| delegation-count | count | Times work was handed to another agent |
| standard-compute-usage | SCU | Normalized compute across models and tools |
Usage Event Records: The Ledger Entries
A Usage Event Record is the structured record of one observed accounting-relevant event: a task starting, a delegation, a tool invocation, a model inference, a workflow step completing, or a task result being verified. It carries a record identifier, the accounting context it belongs to, the event type and time, the observation point, the actor and target, the usage category, the measurements keyed by dimension, the quota state, the result status, sequence information, an evidence reference, and a signature or integrity reference. A receiver must not treat a record as verified only because it is syntactically valid.
How one event becomes a checkable record:
- The event is observed at a declared observation point, with the observation time recorded separately from the time the record is received.
- The event is placed inside its Accounting Context, so the receiver knows which task and domain it belongs to.
- Measurements are attached, each keyed to a dimension from the Metering Profile, with the method that produced each value.
- An evidence reference is attached, pointing at the signature, receipt, hash, or attestation that supports the record.
- The record is exported to the collector, which can check it against the declared rules and raise a finding if it does not add up.
The draft defines eleven initial event categories, from orchestration and execution through tool invocation, model inference, multimodal processing, quota control, gateway forwarding, workflow, result verification, correction, and dispute. Correction and dispute are categories in their own right, which is a deliberate choice: the model expects records to be wrong sometimes, and it gives the correction a first-class place instead of letting it hide as an edit.
| Event category | Example |
|---|---|
| orchestration | Planning and splitting a task across agents |
| execution | Running a step of the task |
| tool-invocation | Calling an external tool or API |
| model-inference | One model call, with its token counts |
| multimodal-processing | Handling image, video, or audio input |
| quota-control | Checking or enforcing a usage quota |
| gateway-forwarding | Passing a task through a gateway to another domain |
| workflow | Advancing a multi-step workflow |
| result-verification | Checking a task outcome under a declared policy |
| correction | Replacing a wrong value while keeping the old one as history |
| dispute | Flagging a record that one side does not accept |
The draft's worked examples show the arithmetic the model is built for. One inference record reports 1,832 input tokens, 412 output tokens, and 960 reasoning tokens, which add to 3,204 total tokens.
A delegation example reports a parent's local 100 tokens plus a child's 40, giving a 140-token subtree total, and a later correction changes the child to 35, giving an effective total of 135, while the old 140 is kept as history rather than silently rewritten. A duplicate-handling example counts a retransmitted record once, at 10, and adds a distinct retry of 7, for 17 in total, because a retransmission is not a second execution.
These examples are illustrative and are not a normative serialization profile, and their values are invented illustrations, not real measurements. That caveat matters for anyone quoting the numbers: they demonstrate the counting rules, and they do not describe any real deployment.
Accounting Evidence References: The Receipts Behind the Records
An Accounting Evidence Reference points at the integrity-protected evidence that supports a Usage Event Record: a signature, a receipt, a hash, an authorization reference, an execution trace, a result attestation, or a human confirmation record. It carries an evidence identifier and type, a location that may be embedded, local, a URI, digest-only, or unavailable under policy, a digest and its algorithm, the asserting entity, the verification method, a validity and retention period, and a disclosure policy.
The draft requires no particular evidence format. Implementations may use JOSE, COSE, JWT, CWT, or selective-disclosure mechanisms, and the choice is left to the profile. What the draft does require is restraint: evidence references must not demand the disclosure of raw prompts, tool results, personal data, or sensitive operational data unless policy allows it and the accounting purpose actually needs it.
Evidence is the hinge of the whole framework, and it is also where the draft is most careful about its limits. A signature binds protected bytes to a signing key under stated validation assumptions, and a digest binds a record to particular bytes when compared against a trusted reference. Neither mechanism on its own proves that usage counters are accurate, that an observation point saw everything, that an action occurred, that a business result is correct, or that a payment was settled, and the draft says so directly.
What "Verifiable" Actually Means — and What It Does Not
In this draft, verifiable means that a receiver can evaluate explicitly identified accounting claims using declared measurement rules, provenance, and evidence. It does not imply that every reported value was independently measured, that every event was observed, or that a signed record proves that a task succeeded or a payment occurred. That sentence is the most important one in the draft, because the word verifiable is easy to over-read.
| A verification can establish | A verification cannot establish |
|---|---|
| That a claim follows the declared measurement rules | That every value was independently measured |
| That a record's bytes match its digest | That the usage counters are accurate |
| That a signature came from the stated key | That the signed action actually happened |
| That an observation was recorded under a declared policy | That the observation point saw every event |
| That a result was checked under a declared policy | That the business result is correct or the payment settled |
The confusion the draft guards against is the gap between a record being well-formed and a record being true. A syntactically valid record with a good signature is still only a claim, and verification is the process of testing that claim against the rules the sender declared. Anything beyond that, such as whether the agent's answer was actually correct, belongs to result verification, a separate category with its own policy.
What the Draft Deliberately Leaves Out
The draft's abstract states its boundary in one sentence: it does not define pricing, charging policy, token issuance, financial settlement, revenue-sharing rules, invoices, or business support system interfaces. The fuller list in its scope section adds tariffs, rating algorithms, token exchange, a general-purpose business support system, an online charging system, a payment protocol, a financial ledger, a discovery or routing or orchestration protocol, a complete identity or trust framework, and a mandatory serialization format or transport protocol.
| Left out | Who defines it instead |
|---|---|
| Pricing and tariffs | The billing system that consumes the records |
| Charging policy and rating | The operator's commercial policy |
| Token issuance and exchange | The token platform |
| Financial settlement and revenue sharing | The settlement system |
| Invoices | The business support system |
| Discovery, routing, orchestration | The agent platform |
| Identity and trust framework | The identity system |
| Mandatory serialization or transport | A future profile or a separate specification |
The design principle behind the boundary is the separation of accounting facts from business charging. The draft standardizes what happened and how it was measured, and it leaves what it is worth to systems that are built to decide that. Disputes follow the same split: the draft defines correction and dispute records, but it does not define arbitration rules, legal process, liability, compensation, or financial settlement.
That restraint is why the draft can stay short at 34 pages. It does not try to be a billing system, a payment protocol, or a trust framework, and a reader who expects any of those will be disappointed in the right way.
How IoA Usage Accounting Relates to Agent Run Metrics
The draft's closest relative is Agent Run Metrics, the per-run JSON format for counting what a single agent run costs, which this draft references normatively as draft-arsentev-agent-run-metrics-02, dated November 1, 2026, one day before this draft's revision. Agent Run Metrics can supply source measurements for this framework, and a mapping between the two must preserve the counting conventions, the local-versus-subtree scope, the reporter namespace, and the missing-report status. No lossless or implemented mapping is claimed in either draft.
The two drafts work at different layers, and that is the point of the reference. Agent Run Metrics describes one run; IoA usage accounting describes the cross-domain world that run lives in, with contexts, evidence, export, collector findings, and correction and dispute relationships. Readers who want the per-run layer first can read What Agent Run Metrics is, and then return here for the layer above it.
| Question | Agent Run Metrics | IoA usage accounting |
|---|---|---|
| What it describes | One run's resource use | Usage across domains and organizations |
| Format | A JSON interchange format | A protocol-visible object model |
| Scope | Per run and per step, local versus subtree | Contexts, profiles, records, evidence |
| Evidence | Counters carried in the report | Evidence references plus verification claims |
| Corrections | Missing-report status | Replacement corrections and collector findings |
| What it does not do | Cross-domain reconciliation | Pricing, settlement, or billing |
The one-day gap between the two drafts is a small detail with a useful lesson. Two teams published complementary pieces of the same puzzle within a day of each other, and the IoA draft cites the -02 revision by name, which means its reference is pinned to a specific snapshot rather than to a moving target. The comparison people ask for, agent run metrics vs IoA usage accounting, is a comparison of layers rather than a contest between rivals.
Where the Idea Comes From: Three Accounting RFCs
The draft does not invent accounting from scratch. It adapts ideas that networks have used for decades, and it names three RFCs as its starting points.
RFC 2975, an introduction to accounting management from October 2000, frames accounting as the collection of resource-consumption data for capacity analysis, cost allocation, auditing, and billing, and argues that no single protocol fits every application. RFC 2866, RADIUS Accounting from June 2000, carries accounting information between a network access server and a shared accounting server in start, stop, and interim records.
RFC 7011, the IPFIX protocol from September 2013, exports flow information from an exporting process to a collecting process using template-based records. The draft itself runs to 34 pages across 14 sections plus an appendix.
| Source | Published | Pages | What the IoA draft takes from it |
|---|---|---|---|
| RFC 2975, Introduction to Accounting Management | October 2000 | 54 | Accounting-management concepts and vocabulary |
| RFC 2866, RADIUS Accounting | June 2000 | 28 | The event-record pattern of start, stop, and interim records |
| RFC 7011, IPFIX Protocol | September 2013 | 76 | The exporter-to-collector model and template-based records |
| draft-zhang-ioa-usage-accounting-01 | November 2, 2026 | 34 | Applies those ideas to agent collaboration across domains |
The three inspirations span 13 years and 158 pages combined, and the IoA draft is shorter than any one of RFC 2975 or RFC 7011 alone: 20 pages shorter than RFC 2975 and 42 pages shorter than RFC 7011. The whole history of this draft so far runs 364 days, from the -00 posted on May 7, 2026 to the -01 expiring on May 6, 2027, with 179 days between the two revisions and an identical 185-day lifespan for each, so the -01 is a same-length renewal rather than an extension of the -00. The -00 itself expired on November 8, 2026, and the -01 carries the same 185 days of validity from its posting date.
The lineage also sets expectations about pace. RADIUS accounting and IPFIX each took years to move from idea to standard, and the IoA usage accounting draft is four days old. Its value today is as a shared vocabulary for builders, not as a settled rule, and the next revision will show whether the wider community picks the vocabulary up.
Who should pay attention now depends on what they build. Platform teams shipping multi-agent products can adopt the vocabulary today, because naming the five pieces costs nothing and makes later interoperation easier.
Agent-infrastructure builders should track the revisions and prototype the object model, since the next version may change the details. Billing and finance teams can wait, because no pricing or settlement is defined here.
Standards watchers should look for a -02 revision or a working-group adoption, which would be the first sign that the wider community is picking it up.
Sources
Verifiable Usage Accounting for Internet of Agents, draft-zhang-ioa-usage-accounting-01 — IETF Datatracker, full text, 34 pages, posted November 2, 2026, expires May 6, 2027.
draft-zhang-ioa-usage-accounting-01.txt — IETF archive, plain-text version of the draft.
Datatracker document page for draft-zhang-ioa-usage-accounting — confirms -01 is the current revision and no -02 exists.
Agent Run Metrics, draft-arsentev-agent-run-metrics-02 — IETF Datatracker, the per-run JSON format this draft references normatively, dated November 1, 2026.
RFC 2975, Introduction to Accounting Management — RFC Editor, October 2000, 54 pages.
RFC 2866, RADIUS Accounting — RFC Editor, June 2000, 28 pages.
RFC 7011, Specification of the IP Flow Information Export (IPFIX) Protocol — RFC Editor, September 2013, 76 pages.
iddiff: draft-zhang-ioa-usage-accounting-00 versus -01 — IETF Author Tools, the -00 to -01 change comparison.
Frequently Asked Questions
Is IoA usage accounting an adopted standard?
No. It is an individual Internet-Draft, not a product of an IETF working group, and it would be published as an Informational document, not a Standards Track RFC. Like every Internet-Draft, it is valid for a maximum of six months and may be updated, replaced, or obsoleted at any time.
Does this draft set prices for agent work?
No. The draft deliberately leaves out pricing, charging policy, token issuance, financial settlement, revenue sharing, invoices, and billing interfaces. It defines the accounting records and the evidence behind them, and it leaves what the work is worth to the billing and settlement systems that consume those records.
Does a signed usage record prove the agent's task succeeded?
No. A signature proves only that specific bytes were signed by a specific key under stated validation assumptions. Verifiable here means a receiver can check a claim against the declared measurement rules and the evidence, not that the value was independently measured or that the task succeeded or a payment occurred.
What is a Standard Compute Unit (SCU)?
An SCU is a normalized unit for compute consumption across heterogeneous models, tools, and environments, defined by each Metering Profile. The draft gives no official conversion between SCUs and tokens, seconds, or money, because it defines neither a calibration nor an exchange rate for the unit.
When does the draft expire, and what happens then?
The -01 revision expires on May 6, 2027, which is 181 days after this guide was written on November 6, 2026. If no newer revision replaces it by then, the draft lapses, and anyone still using its vocabulary would be relying on an expired proposal rather than a live document.
