AI Operations

Per-Task Cost Attribution: The Observability Layer Small-Business AI Workers Are Missing

Tracing, token dashboards, and eval gates tell you what an agent did. Per-task cost attribution tells you whether it paid for itself. A Novacore operator playbook for 2026.

Published 2026-07-12 · 9 min read

Why most AI observability stops one number short

Most AI observability stacks in 2026 are very good at three things and one thing only half-heartedly. The three things they do well: tracing the LLM call, recording the tool call, scoring the final output. The one thing they under-instrument: per-task cost attribution, defined as the total cost of producing a single, named, auditable unit of business output, divided across the agent runs that produced it. A DigitalApplied survey of agentic stacks in early 2026 found that token cost and tool cost are visible in traces, but only a minority of operators can answer 'how much did this specific deliverable cost to produce' in under five minutes. Novacore's own internal experience matches that finding. The eval gate passes. The trace looks clean. The dashboard shows a green run. The P&L of the venture is still in the dark. The reason is structural: most observability tools were designed for software engineers who wanted to debug latency and reliability, not for operators who need to defend a margin.

The cost attribution problem, stated plainly

A small business running an AI worker pipeline in 2026 has at least four distinct cost categories that all show up inside a single agent run: model input tokens, model output tokens, tool API calls (third-party costs charged per call, not per token), and operator review time (a real line item, because the AI content quality gate is a paid human gate, not a free one). Appscale's 2026 OpenTelemetry pattern guide for AI observability calls this the 'gen_ai.* attribute namespace' problem: the standard spans capture tokens, but cost attribution is left to a separate rollup that most teams never finish wiring. For a small business, the consequence is that the per-task cost is fuzzy. A 'draft this article' task that consumed $0.80 in model tokens and another $0.40 in tool calls and 25 minutes of human review time has an actual cost near $4.20 once labor is priced in. Without attribution, the task looks like a $1.20 task. The venture looks profitable when it is not. The cost attribution problem is therefore a margin problem, and margin problems compound quietly.

What per-task cost attribution actually requires

Per-task cost attribution at the small-business level needs five primitives, not a vendor: (1) a stable task_id that survives across the agent's spans, tool calls, retries, and review queue, ideally written into the task JSON itself; (2) a token price table that the rollup script reads at task completion, not hardcoded into the agent; (3) a tool-call price table maintained by the operator as tools and vendors change, again read at rollup time; (4) an operator-time log keyed by task_id, captured from the review queue; (5) a daily rollup that produces a single line per task with model_cost, tool_cost, labor_cost, total_cost, and a margin field when the task has an associated revenue line. The rollup is a small Python script, not a SaaS subscription. The 2026 ADEVS pricing guide for small-business AI integration reports the typical 'observability platform' SaaS spend at $200 to $2,000 per month, which is exactly the line item that disappears when the same function is built as a local script reading the same data. None of the five primitives require a vendor to be useful. All five require discipline to be maintained.

The Novacore operating pattern

Novacore runs AI workers against a single shared task queue. Each task file in sarah-hq/tasks/pending/ contains a task_id and, when relevant, an expected_value field. When the employee picks up the task, it copies itself into sarah-hq/tasks/in-progress/ and writes a heartbeat with a started_at timestamp. When the work is reviewed and the report is written to sarah-hq/inbox/sarah/, the reviewer's report is paired with the task_id. The rollup script at the end of the day joins three tables: the task file, the in-progress heartbeat, and the inbox report. Model cost is calculated from token counts in the heartbeat and the live price table. Tool cost is calculated from explicit tool_call lines in the heartbeat. Labor cost is calculated from the difference between completed_at and reviewed_at times multiplied by a configurable hourly cost (currently $25/hour for Sarah's review time, $40/hour for higher-stakes work). The rollup writes one line per task into a daily ledger. The weekly P&L reads the ledger, groups by venture, and reports margin. None of this is novel. All of it is the difference between a venture that knows its numbers and one that is guessing.

Why eval gates and observability alone do not solve this

Eval gates answer the question 'is this output good enough to ship?' Observability answers the question 'what did the agent do, and did it fail?' Neither answers the question 'is this venture making money?' The gap is filled by cost attribution. The Q1 2026 Loonis citation-rate benchmark study found that the most-cited AEO pages in 2026 were not the most carefully observed ones, but the ones whose authors could answer a different question: 'what does it cost me to keep this fresh?' Citation rate and cost per citation are tightly coupled. A page that costs $40 to keep current and earns five citations a year is unprofitable. A page that costs $4 to keep current and earns five citations a year is a moat. The 30 percent citation-rate uplift that comes from including the current year in titles and H2s (per the Loonis Q1 2026 finding) only matters if the cost of producing the page is known. AEO without cost attribution is SEO from five years ago with worse dashboards.

The five numbers every operator should be able to produce

By the end of this week, an operator of a small AI-run business should be able to produce, in under five minutes, the following five numbers from their task queue and ledger: (1) the average per-task cost over the last 30 days, broken out by model cost, tool cost, and labor cost; (2) the per-task cost variance by task type, with the cheapest and most expensive task types ranked; (3) the per-venture margin for the trailing 30 days, with model and tool cost allocated to each venture; (4) the citation rate per article produced, where the article has been live for more than 30 days; (5) the cost per shipped deliverable, including the cost of tasks that were killed before shipping. None of these numbers require a vendor. All of them require the five primitives listed earlier. If a small business can produce these five numbers, it can answer the question that matters: 'if I scale this worker from one to five, does the unit economics hold?' If it cannot, scaling is a guess.

What to build this quarter

The practical project for a small business this quarter is to ship the per-task cost attribution layer before adding any new AI worker. The sequence is: (1) pick one task type that already runs at least weekly, such as 'draft blog article from sources' or 'respond to inbound lead,' and instrument it with a stable task_id and a token and tool log; (2) write the daily rollup script that joins the task file, the heartbeat, and the inbox report into a single per-task cost line; (3) write the weekly P&L script that reads the daily ledger and groups by venture; (4) set a review cadence so the rollup is read by the operator every Monday and the P&L every Friday; (5) only after the cost layer is producing real numbers, add the next AI worker. The order matters. Adding workers before the cost layer is the small-business equivalent of opening more restaurants before the existing ones are profitable. The discipline is unglamorous, the compounding is real, and the moat is the operator's ability to make decisions on numbers that are not invented.