AI agent monitoring is not enough. Teams need AI work attribution.

AI agents are no longer sitting in demo environments.

They are writing code, generating customer replies, classifying documents, summarizing meetings, drafting outbound sequences, searching knowledge bases, and running internal workflows. Some run inside production applications. Others run quietly on employee laptops through tools like Claude Code, Cursor, Codex, Cline, Windsurf, and local model runners.

This creates a new kind of operational problem.

Most teams can see pieces of their AI activity. They may know how many tokens were used, whether a model call succeeded, or what showed up on the provider invoice. But those signals rarely answer the questions leaders actually ask once AI becomes part of daily work:

• Which agents are running across the company?
• What is each agent costing?
• Which product features are driving AI spend?
• Which customers or users are creating the most AI cost?
• Which local developer tools are touching sensitive projects?
• Which outputs were accepted, edited, sent, discarded, or failed?
• Which workflows created real value, and which simply created cost?

This is where the category needs to move beyond basic LLM observability. The next layer is AI work attribution, and beyond that, a loop that acts on what it finds.

The model call is not the unit that matters

LLM observability is useful. It helps teams inspect prompts, completions, latency, token usage, and traces.

But an AI agent is not just a model call.

An agent session may include multiple model calls, tool calls, retries, file reads, API requests, handoffs, approvals, and downstream actions. A coding agent may operate inside a local repository. A product agent may generate a customer-facing response. A workflow agent may run unattended for hours.

If you only observe the model call, you miss the shape of the work.

The more useful unit is the agent session:

• who or what started it
• which agent ran
• which model was used
• what tools were called
• what data or files were accessed
• which product feature or internal project it belonged to
• how much it cost
• how long it ran
• whether it behaved normally
• what outcome it produced

That context is what turns AI telemetry into something operationally useful.

Cost without context is just a bill

Most teams eventually discover that AI spend is harder to explain than expected.

A provider dashboard may show total spend by model or API key, but it usually cannot tell you which product feature, customer, team, repository, or workflow created the cost.

That gap matters.

A spike in AI spend could be healthy growth from a successful product feature. It could also be a routing bug sending simple tasks to an expensive model. It could be an abandoned automation. It could be a retry loop. It could be three users repeatedly triggering a high-cost workflow.

Without attribution, all of those scenarios look like the same thing: a bigger invoice.

The better question is not only "how much did we spend?"

It is:

What AI work did we pay for, who caused it, and was it worth it?

The missing metric: cost per useful outcome

One of the most important AI metrics is also one of the least visible: cost per useful outcome.

A model call is not expensive or cheap in isolation. Its value depends on what happened next.

For a product team, that might mean:

• Was the generated reply accepted?
• Was the draft edited?
• Was the sequence sent?
• Was the summary used?
• Was the recommendation ignored?
• Did the workflow complete?
• Did the user discard the output?

A $0.05 model call that produces an accepted customer response may be a good investment. A $0.002 call that is discarded thousands of times may be a margin leak. A $10 agent session that completes a high-value workflow may be justified. A $10 session caused by a runaway retry loop is an incident.

The goal is not simply to reduce AI spend.

The goal is to understand which AI work is worth paying for.

That requires telemetry that connects cost to context and outcomes, not just tokens and latency.

Local agents are part of the production reality

AI observability discussions often focus on production applications. That misses a large and growing surface area: local AI agents.

Developers are using coding agents every day. These tools can read files, modify code, run shell commands, call models, and interact with proprietary repositories. They are part of the engineering workflow, even if they do not run inside the production app.

For engineering leaders, this creates practical questions:

• Which local AI tools are being used?
• Which projects and repositories are they touching?
• Which models are they calling?
• Which sessions ran unusually long?
• Which workflows happened after hours?
• Which activity maps to real cost?
• Did an agent run unattended?

This is not about surveillance. It is about operational visibility.

If AI agents are becoming part of how work gets done, teams need a way to understand that work across both local and production environments.

Product agents need business context

Production AI agents need a different kind of attribution.

For an AI feature embedded in a SaaS product, model-level metrics are not enough. Product and engineering teams need to connect AI activity to the user experience.

That means capturing context like:

• feature
• screen
• route
• user action
• customer
• account plan
• entity ID
• workflow ID
• final outcome

With that context, teams can answer much better questions:

• Which AI features cost the most?
• Which customers are driving AI usage?
• Which workflows have the highest cost per accepted output?
• Which model choices are hurting margin?
• Which AI experiences are growing fastest?
• Which outputs are repeatedly discarded?

This is where AI observability becomes product intelligence.

Governance starts with an action ledger

Cost and outcomes are only one side of the problem.

Agents also create governance questions.

As agents gain access to tools, files, APIs, and production workflows, teams need a reliable record of what happened. That does not mean every organization needs heavy approval flows on day one. But they do need a trustworthy action ledger.

A useful record should show:

• what the agent did
• when it did it
• which tools it used
• what data it accessed
• whether the action matched policy
• whether approval was required
• whether the session behaved unusually
• whether the record can be exported as evidence

When something goes wrong, traces alone are rarely enough. Teams need to reconstruct the agent's work.

The next layer isn't more visibility. It's a loop that acts on it.

Everything above, sessions as the unit, cost tied to outcome, an action ledger, still describes a system that watches and reports. That's necessary. It isn't sufficient.

Visibility answers what happened. It doesn't stop the next session from costing 3x what it should, and it doesn't catch the risky command before it runs. A ledger that shows an agent executed an unapproved action is evidence. It isn't a gate.

The next layer needs three things visibility alone can't provide: a way to catch oversized or risky work before it runs, not just log it afterward; a way to stop a session that's already gone wrong, in the moment, not the next morning; and a way for the system to get better at both, instead of every team hand-tuning the same dashboards forever.

Call that a control loop for AI work: the same session-level, outcome-tied visibility described above, plus the ability to act on it, before, during, and after, on developer laptops and inside production, together. We wrote the full breakdown of how the five steps work here.

The work is already happening. The real question is whether anything acts on it.

AI agents are writing code, generating replies, and running workflows across the company right now, on laptops and in production, whether or not anyone is watching closely.

Session-level visibility, cost tied to outcome, and an action ledger are the foundation. But a foundation isn't the finish line. The teams that get ahead of this won't just see the work clearly. They'll have something in place that catches the expensive session before it runs, stops the one that's going wrong, and proves what the rest were worth.

For engineering, that's catching the runaway session before it burns the sprint's budget, not reading about it after. For product, it's a feature's AI cost decomposing in a filter the day the bill jumps, not a week of grepping logs. For finance, it's knowing where the AI budget actually went before the invoice arrives, not after. For security and governance, it's a gate on the risky action before it runs, not just a record that it happened.

That's the control loop this piece has been building toward.

If you're a developer, AIWatcher OSS brings this to Claude Code, Codex, and Cursor sessions today. Free, open source, local-first. If you run a team or ship AI features, see how the same loop covers both surfaces at getaiwatcher.com.