Aliz AI Telemetry: Q3 2026 Review
OpenTelemetry usage data · July–September 2026 · first quarterly review
AI activity at Aliz is substantial, and September brought a clear jump in agentic workflow activity. But the strongest workflows still have limited recorded reach, while cost and usage are concentrated among a relatively small set of aliases.
The next phase of AI Transformation should not be “use more AI.” It should spread the practices that already work, strengthen quality loops, and connect AI activity to delivery outcomes.
01 - What this dataset can tell us.
This review combines six exports from the Aliz AI Telemetry dashboard, filtered to 1 July–30 September 2026. They cover calls, tokens, estimated cost, services, skills, and skill triggers.
This is organisation-wide telemetry, not engineering-only statistics. The current exports are not divided by department, so they cannot support comparisons between Engineering and other parts of Aliz or show which department drove a result.
The exports measure activity, not value. A call is not a completed task, and a skill event is not a successful delivery. Read the figures with these additional constraints:
- User identifiers are aliases, not cleanly deduplicated people.
- Only the skill exports contain dates. Calls, tokens, and estimated cost are period aggregates, so monthly trends cannot be reconstructed for them from these files.
- Service-level and user-level exports differ by 4.9% in total tokens.
- Provider implementations emit different kinds of telemetry events, so call counts are not interchangeable units of productivity.
- Estimated cost is a dashboard calculation, not actual spend or a verified invoice.
02 - Skill activity doubled, mostly through chaining.
July and August were effectively flat at 1,325 and 1,315 skill events. September reached 2,647, an increase of 101% month over month. Nested-skill events rose from 416 to 1,184 and contributed 58% of the total increase. That is consistent with more composed, chained workflows rather than only more manual slash-command use.
This is good evidence that some users are moving beyond one-shot prompting. It is not evidence that the number of active users doubled: the dated skill exports do not include monthly unique aliases.
03 - Skill adoption is real; standardisation lags.
The July AI survey covered engineers and found that 88% of respondents used skills, up from 31% in March. This organisation-wide telemetry cannot validate that result because it is not segmented by department. It provides separate context: most named workflows in the telemetry are still used by very few aliases.
Of 346 skill labels, 238 (69%) have one reported alias and 299 (86%) have at most two. Several
high-activity workflows—including session-close, pr-prep, and ticket-workflow—show one or two
aliases despite dozens of events. By contrast, artifact-design reached 35 aliases and
code-review reached 19. The generic custom_skill label reached 50 aliases but groups different
workflows together, so it tells us little about which practices are spreading.
This is the biggest enablement opportunity in the data. We have many local experiments, but too few have become shared organisational capabilities. The job now is to identify the workflows that save time or improve quality, make them easy to discover, and help teams adapt them—not to maximise the number of skill labels.
04 - Review activity is rising, but quality is still unmeasured.
The exact code-review skill grew from 6 events in July to 46 in August and 105 in September.
For context, the engineering-only survey found that line-by-line human review fell from 57% to 26%
and 24% of respondents said they delegate review to another AI. These are different populations,
so the telemetry trend is not a direct counter-signal to the survey.
But the two findings do not cancel each other out. Telemetry tells us that a review workflow ran; it cannot tell us whether the review found defects, whether tests covered the risky paths, or whether the resulting change was maintainable. We should treat growing review automation as a reason to add stronger outcome measurement, not as proof that quality is handled.
05 - Tool use and estimated cost are concentrated.
Claude Code variants and Cowork account for 896,816 of 1,000,320 recorded calls (89.7%). Cowork appears under 49 aliases; without verified role mappings, the dataset cannot separate engineering from other usage. Provider implementations also emit telemetry differently, so call counts should not be used as a cross-tool productivity ranking.
The user-level export reports approximately USD 163.1k in estimated usage-based cost across 91 aliases.
Estimated cost approximates what Aliz would have paid under usage-based pricing instead of subscriptions. It is not actual spend. Copilot's provider-native cost signal is a premium-request multiplier rather than USD, so this aggregate should not be used to compare provider economics.
The five highest-cost aliases account for 38.4%; the top ten account for 54.0%. This is useful for finding where to investigate effective patterns and inefficient loops. It is not a bill, a quota proposal, or a performance leaderboard.
06 - What AI Transformation should do next.
- Turn power-user workflows into shared defaults. Select a small set of high-value workflows, document the outcome each is meant to improve, and distribute them through teams. Pairing and short demos should be organised around working artifacts, not generic prompting advice.
- Measure delivery outcomes alongside activity. Add privacy-conscious, team-level views of cycle time, change failure, escaped defects, test signal, review findings, and rework. We need to learn where AI improves delivery—not only where it generates tokens.
- Make automated quality loops the standard. Every scaled workflow should have explicit verification: tests, linters, security checks, domain-specific review, and a clear point where human judgment is required. This directly addresses the survey's concerns about lost codebase understanding and review load.
- Repair the measurement layer before setting targets. Normalise identities, add department or role mappings, document provider-specific metric semantics, and reconcile the 4.9% difference between service-level and user-level token totals. Adoption or cost targets built on the current aliases would create false precision.
- Manage cost per outcome, not cost per person. Use concentrated consumption to find both exemplary workflows and waste, then optimise context, models, caching, and loop design. Raw spend without delivery context should not decide who gets access.
Conclusion - move from adoption to repeatability.
The data says Aliz has crossed the basic adoption threshold. Activity is meaningful, chained workflows are growing, and review automation is increasing. The constraint has moved: effective practice is not spreading fast enough, and we cannot yet connect the activity to better delivery.
The next step is therefore distribution plus proof: make strong workflows reusable, make quality controls automatic, and measure whether they improve outcomes. That groundwork also hints at the emerging agentic software-factory model described at OpenAI, where humans increasingly define intent and feedback loops while agents execute more of the lifecycle. OpenAI's own experiment makes the same point: greater autonomy depends on better scaffolding, context, and controls.
- Source: AI Telemetry dashboard exports, 1 July–30 September 2026.
- Telemetry Architecture.
aliz.ai