Cycles

Appearance

← Blog

· Cycles Team · 11 min read

runtime-authoritygovernanceauditfinopscompliancecostsagentsengineering
Share Share

The AI Agent Audit Trail You're Already Building ​

A platform-engineering lead got three questions in one week:

  • The CFO: "What does it cost to serve customer X this quarter?"
  • The auditor: "Show me evidence that the agent's spending was authorized, with rationale and timestamp."
  • The data team: "Why is our AI bill 6× engineering's? Can you break it down by team?"

Three different stakeholders. Three different vocabularies. One underlying need: correlated records that explain who proposed an action, what happened, when, how much budget settled, and which application and budget controls applied.

The lead's existing tools couldn't answer any of them cleanly. The provider invoice was one line. The APM trace had spans but no costs. The SIEM logged tool calls but not money. Each question would have meant a separate instrumentation project.

It turns out the data was already there. The team had deployed Cycles for runtime authority — to stop runaway spend and block risky actions before they execute. The byproduct of that enforcement is a ledger-ready record of every metered agent action: structured, idempotent, attributable, and exportable into audit, finance, and observability systems. The lead had been sitting on the answer to all three questions for months.

This post is about that byproduct. What runtime authority also gives you when you turn it on, and why three different teams in your org each get something they've been struggling to build.

What runtime authority actually persists ​

The core Cycles lifecycle is reserve → execute → commit or release, with decide() available as an optional preflight check before reservation. At an instrumented mandatory boundary, execution proceeds only after the applicable budget is locked, and settlement records the best-known actual usage supplied by the integration.

The bookkeeping story is the byproduct. Persisting lifecycle operations produce structured records; non-persisting preflight evaluations must be logged by the caller:

OperationWhat it recordsWhy it matters as evidence
decide() (optional preflight)Returns subject evaluation, decision (ALLOW / ALLOW_WITH_CAPS / DENY), reason_code, and affected scopes but does not persist themCaller can write an application audit record with machine-readable rationale
reserveactual lock against the budget, hold token, expiryAuthoritative "we said yes and here's what we held"
commitcaller-reported best-known actual cost (separate from estimate when available), final balance impact, lifecycle closeAuthoritative "this is what the integration settled"
release / expired-reservationunused portion returned to the budgetAuthoritative "this is what was given back"

The subject hierarchy supports up to six levels — tenant, workspace, app, workflow, agent, and toolset. The more consistently you populate it, the better the attribution: aggregating by tenant gives cost-per-customer, by workflow gives cost-per-conversation, by agent gives cost-per-component. The point is that attribution is structural — a field on the record, not a SQL join across log streams stitched together after the fact.

What you can have after sustained production use is a lifecycle ledger with fields suited to financial reconciliation: which Subject and action context were submitted, when, how much was reserved and committed, and which budget scopes were affected. Join it to application authorization and outcome records before treating it as a complete action history.

Risk and compliance: audit evidence by default ​

Regulators have caught up to the AI agent surface. For high-risk AI systems, EU AI Act Article 12 requires automatic logging capabilities that support traceability and post-market monitoring over the system's lifetime. Cycles contributes concrete reservation and settlement records with scope, amount, status, and timestamps. Applications still need to preserve non-persisting preflight denials, tool arguments, identity-policy outcomes, and business rationale. SOC 2 Type II audits can also bring agentic systems and their controls into scope, while ISO 42001 supplies an AI management-system framework; neither makes the Cycles ledger a complete compliance record by itself.

The standard pattern for satisfying these is to bolt on an audit logger after the fact: pick fields, write to a separate store, hope the schema covers what an auditor will ask for. The pattern is fragile because it's secondary — the auditor and the engineer disagree on what's worth logging, and engineering wins by default.

Cycles improves that foundation. Reservation and settlement records are both enforcement state and an audit substrate; when you use decide(), copy its non-persisting response into your application audit store. Depending on the operation and deployment, the combined records can carry:

  • The subject scope, with up to six levels of attribution
  • The decision and the reason_code (machine-readable rationale)
  • The idempotency key, when supplied, which supports replay-safe handling on retries
  • The timestamp and the actor

When an auditor asks "can you show me an action that was attempted but blocked, with reason and authority?" the answer comes from the application audit record for preflight outcomes plus any correlated lifecycle evidence. When they ask "how do I know this record was actually produced by Cycles at the time you say?" — if you stored the raw HMAC-SHA256-signed webhook body, the signature, and the X-Cycles-Event-Id in your audit store, you have evidence that Cycles delivered that event, with a primitive that lets you safely dedupe and replay. The ledger becomes tamper-evident only to the extent your downstream store preserves the signed payload — that piece is on the operator, not the protocol.

The companion post — The AI Agent Governance Framework — maps specific regulatory clauses to runtime enforcement controls. This post is the inverse: it explains why the protocol already produces the evidence those clauses ask for, before anyone tells you the regulator is asking.

Finance and FP&A: cost attribution and forecasting ​

The CFO's question — what does it cost to serve customer X? — is a unit-economics question. It's the question that any company building AI features into a product with a revenue model has to answer eventually, and most can't.

The reason most can't is that the cost data lives in three places: the LLM provider invoice (one line), the application logs (per-request token counts that nobody aggregates by customer), and the cloud bill (compute and storage, customer-agnostic). To get cost-per-customer you have to stitch.

Cycles' subject hierarchy collapses the stitch. When your integration populates the subject hierarchy consistently, each commit is tagged with the customer (tenant), the feature (app), the workflow, and the agent. Aggregating by tenant gives cost-per-customer. Aggregating by app gives cost-per-feature. Aggregating by workflow gives cost-per-conversation. The math is SELECT SUM(committed) GROUP BY ....

The deep dive on cost-per-conversation, cost-per-user, cohort margin, and the full unit-economics picture is in AI Agent Unit Economics: Cost and Margin Analysis. Read that for the math.

What that post doesn't lead with is forecasting. Once you have a quarter of structured commit data, the trajectory is computable. Token velocity per workflow, peak vs average, the slope of the spend curve as a feature scales — these are the inputs to next-quarter financial planning. They're also the data you bring into a board meeting when an investor asks about COGS for the AI feature: not a slide that says "estimated $X per seat," but a chart with actuals and a credibility-bearing forecast.

The before-and-after for a finance team:

QuestionWithout per-action ledgerWith Cycles ledger
What did customer X cost?Estimate from logs + heuristicGROUP BY tenant on commit data
What's the margin on Feature Y?"Hard to say"Cost subtracted from feature revenue
What's the run-rate trajectory?Provider invoice + spreadsheetLive aggregation against committed data
Which 5 customers drive 50% of spend?Quarter-end exerciseStanding query

None of this requires Cycles to be a billing engine or a financial data warehouse. It just has to be the source record system the warehouse pulls from.

Platform engineering: chargeback and showback ​

The third stakeholder is closer to home. Every platform team running AI infrastructure inside a larger company is being asked the same question with increasing pointedness: which team is burning the AI budget?

Today the answer is usually some version of "I don't know — the OpenAI bill is one number." That answer was acceptable when the AI bill was a footnote on the cloud spend. It stops being acceptable when the AI line passes the database line, which is happening.

Cycles' subject hierarchy gives platform teams a clean answer: workspace and app levels are the natural mapping for organizational structure. A workspace corresponds to a team, an app corresponds to a service or product surface, and the tenant corresponds to the company or environment. Issuing API keys per workspace gives the platform team a metered surface that maps cleanly to cost centers.

Querying GET /v1/balances?tenant=acme&include_children=true returns balances at every scope underneath, in the shape documented in the API reference:

json
{
  "balances": [
    {
      "scope": "workspace:data-team",
      "scope_path": "tenant:acme/workspace:data-team",
      "spent":     { "amount": 184320, "unit": "USD_MICROCENTS" },
      "remaining": { "amount":  15680, "unit": "USD_MICROCENTS" }
    },
    {
      "scope": "workspace:engineering",
      "scope_path": "tenant:acme/workspace:engineering",
      "spent":     { "amount":  41200, "unit": "USD_MICROCENTS" },
      "remaining": { "amount": 158800, "unit": "USD_MICROCENTS" }
    }
  ]
}

(Excerpted — the full response also returns allocated, reserved, debt, and is_over_limit per scope.) The data team's question — why is our AI bill 6× engineering's? — answers itself. The chargeback report becomes a standing query, not a quarter-end fire drill.

A side benefit worth flagging: this kills shadow AI spend. Engineers can't quietly move workloads off the metered surface unless they leave Cycles entirely, and leaving Cycles costs them the runtime authority that's stopping the runaway loops they've already been bitten by. The metering is sticky because the enforcement is valuable — different from observability tools, which tend to atrophy because nobody's blocked when they're missing.

What makes this a ledger, not a log ​

A reasonable objection: every observability tool produces records. Why call this a ledger?

The distinction here is operational. A log is usually optimized for debugging, while a settlement ledger emphasizes idempotent mutations, balances, and lifecycle state that accounts can be reconciled against. Cryptographic proof is optional and depends on enabling CyclesEvidence or preserving signed webhook deliveries.

Cycles supplies several of those ledger properties:

  • Idempotency is protocol-defined, especially around commit/release and retry safety. When an idempotency key is supplied, the server enforces replay semantics per tenant, endpoint, and key: successful replays return the original response, while mismatched payloads return IDEMPOTENCY_MISMATCH. That is what prevents retries from double-charging. The glossary covers the broader semantics.
  • Webhook deliveries are HMAC-SHA256 signed with a unique X-Cycles-Event-Id per event and delivered with at-least-once semantics. Subscribers can verify the delivered body and deduplicate by event ID; this transport signature does not make every stored lifecycle row independently signed.
  • Events carry W3C trace context (traceparent / X-Cycles-Trace-Id), which means cross-system correlation — the ledger entry, the application trace, and the LLM provider span can be tied together by ID, not by timestamp guesswork.

That makes the lifecycle records useful alongside an APM trace: the trace explains execution, while the Cycles records explain budget holds and settlement. For deeper coverage of the webhook-delivery side, see Webhook Idempotency Patterns for AI Agent Budget Events.

Honest scoping: Cycles is not a billing engine, not a SIEM, and not a FinOps platform. It is a source of scoped budget lifecycle data that those systems can consume. Datadog, Honeycomb, CloudZero, Splunk, and the various LLMOps platforms each cover slices of the larger story. Your integration supplies the tool identity and business context, logs non-persisting decisions, and correlates external outcomes with what Cycles reserved and committed.

What this post does not yet claim ​

Some byproducts are real but require additional integration work, and we don't want to overclaim:

  • Pricing-model enablement. Usage-based pricing, credit wallets, and tiered plans need a billing engine downstream. Cycles produces the metering input that Stripe/Lago/Orb consume; we don't produce invoices.
  • Carbon and ESG reporting. Token counts feed carbon estimates well, but Cycles doesn't ship the carbon-coefficient mapping. The plumbing is there; the partnership work isn't.
  • VC and acquisition due diligence. The data exists in the ledger; turning it into a board deck or an acquisition data room is on you. We're not in the analyst-services business.

These are roadmap pointers and partner-integration territory, not features being claimed today.

Why this matters in production ​

Most AI infrastructure layers solve one stakeholder's problem. Observability platforms serve operations. The OpenAI dashboard serves engineers. A separate audit log serves compliance — usually built reactively after a question is asked.

The Cycles ledger can anchor answers for all three stakeholders when it is combined with the application's decision and action logs. Risk and compliance get correlated preflight rationale and lifecycle evidence. Finance gets per-subject cost attribution. Platform engineering gets workspace-level chargeback. The reason it works is that each of those stakeholders is asking the same underlying question — "who took which action with what authority and at what cost" — phrased in three different professional vocabularies.

You build the enforcement layer because runaway spend and risky actions are real and acute. You get the ledger because the act of enforcing produces records that, by protocol design, are structured the way an auditor, a CFO, and a platform engineer all need them.

The circuit-breaker framing is the front door. The ledger is the back office that keeps the company running.

Last updated: