Writing
Part 3: From Proxy Logs to Intelligence - Enterprise AI Observability
Every enterprise wants to know whether AI is helping. Most start by counting licenses, which answers a different question — who could be using AI, not whether anything changed. The honest signal is sitting in the request stream the whole time: what people ask, which tools agents call, where they fail, what data gets touched, and which workflows keep repeating.
Trace it like a distributed system
A proxy log by itself is a pile of requests. The useful unit is the trace: user identity, task intent, model version, tool calls, latency, cost, the artifact that got generated, the edits a human made to it, and what finally happened downstream. Without that join you can count usage, but you can't reason about value or risk. You know the meter is spinning; you don't know what it bought.
So the design should look like distributed tracing, not survey analytics. Every agent run gets a trace id. Every tool call is a span, with inputs, outputs, redaction status, authorization decision, retry count, and error type. Every human approval or override attaches to the same trace. That's the difference between AI work you can debug and AI work you can only have opinions about.
What the logs are actually for
The thing the traces reveal first is that adoption is not uniform. A small number of people find the frontier early — they restructure whole workflows around the tools — while most usage stays at the shallow end, AI as a slightly better search box. Both show up identically in license counts. They look completely different in traces. The observability system exists to see that gradient: find the power users, find the recurring friction, and feed both back into enablement and tooling. (Part 7 of this series is about the program you build on top of that signal.)
The questions worth asking of the data are operational, not philosophical. Which workflows show real quality or cycle-time improvement? Where do agents retry, hallucinate tool usage, or ask for permissions they shouldn't need? Which prompts and tools correlate with incidents, reverts, or human overrides? Which teams are blocked — by missing context, missing tools, or policy nobody has clarified?
Privacy is load-bearing
One thing I'd do differently than most first attempts: design the privacy boundaries, retention rules, and redaction before collecting anything. Not as compliance theater — because the system only survives if engineers trust it. The moment proxy logs feel like surveillance, people route around them, and your instrument panel starts measuring the subset of work people are willing to show you.
The proxy is not just a security checkpoint. It's the instrument panel for the whole AI transition. And once you can see what agents are doing, the next question becomes unavoidable: what should be allowed to run unattended, and on what infrastructure? That's Part 4.
This is Part 3 of the AI-for-Work series. Next: Part 4: Agent Orchestration at Scale.