RCLM Signals: Patterns for Finding AI Workflow Waste

RCLM Signals is a new way to find repeated workflow problems inside captured AI sessions. Instead of only showing token totals or session counts, Signals looks for specific patterns that usually point to wasted context, poor handoffs, missing project knowledge, policy drift, duplicated work, or avoidable model cost.

A signal is not a verdict. It is an investigation lead with evidence behind it. Admins can start from a pattern, open the related sessions, and decide whether the fix is a user habit, a project artifact, a team process, or an org policy change.

What Signals detects

The current Signals set covers ten patterns.

| Code | Signal | What it finds | | --- | --- | --- | | P1 | Restart churn | Same project restarted repeatedly instead of continuing from useful context. | | P2 | Groundhog files | Same files repeatedly read across sessions or contributors. | | P3 | Exploration without landing | Heavy reading/searching with little or no editing. | | P4 | Session idle gaps | Sessions where the user waits too long after the assistant responds. | | P5 | Session bloat | Sessions continuing past the user's normal completion point while context keeps growing. | | P6 | Compression policy drift | Supported compression is expected to enforce, but active sessions are off or observe-only. | | P7 | Project onboarding cost | New contributors spend materially more tokens than veterans on similar project work. | | P8 | Cross-team duplicated work | Separate teams repeat substantially similar work without reusing earlier results. | | P9 | Context-weight burn | A session carries much more cached context per tool call than the user's baseline. | | P10 | Model-task mismatch | A costly model is used where matched lighter-model work performs comparably. |

These are intentionally specific. “High token usage” by itself is not enough. Signals tries to answer a more useful question: what kind of waste is this, and what should someone inspect next?

How it works

Signals are calculated from captured session metadata, normalized tool calls, project attribution, team membership, policy snapshots, model usage, provider-reported token data, and session similarity data.

The backend evaluates patterns over a trailing weekly window. For each evaluated pattern, it records a score. If the score crosses the pattern threshold, it creates an open signal with evidence.

Examples:

• P1 looks for same-project sessions restarted shortly after the previous session ended. Very short gaps are treated as automatic restarts. Longer gaps inside the restart window count as deliberate restart pairs.
• P2 looks at file reads across sessions. It includes native read tools and common shell-read patterns, then canonicalizes paths so repeated reads of the same file are counted together.
• P3 compares exploration calls to edit calls. It fires when a session does enough reading/searching and the exploration-to-edit ratio is high.
• P4 counts sessions where the next user prompt arrives more than the configured threshold after the assistant response. The default is 20 minutes. P4 is session-finding, not team-ranking: one long wait in a session is enough to make that session worth reviewing.
• P5 compares a current session to that user's own baseline, so naturally long-running users are not judged against a global constant.
• P6 checks whether active sessions are following the org's intended compression enforcement behavior.
• P7 compares onboarding sessions against veteran sessions on the same project and category of work.
• P8 uses conservative session similarity evidence and requires cross-team duplication before it fires.
• P9 uses provider-reported cache/context data where available.
• P10 compares expensive-model sessions against lighter-model sessions within the same user, project, and task category.

The important design choice is that Signals carries evidence. The admin should not have to guess why something fired. A useful signal should point to sessions, files, models, projects, or teams that can be inspected.

How to use it

Start with the pattern code, then open the evidence.

If P2 fires on a project, the likely fix is not “read less.” It may be a missing project map, a stale README, or a file that needs a durable explanation.

If P3 fires, review the session prompt and entry point. The fix may be asking for a file, symptom, failing command, or suspected module up front instead of starting from a broad goal.

If P4 fires, open the sessions. A long assistant-to-user gap may mean interruption, review time, abandoned work, or a missing handoff. If those waits are expected for your team, raise the threshold. If they are avoidable, add a handoff convention.

If P10 fires, do not automatically ban premium models. Use the evidence to find repeated cases where lighter models appear good enough for similar work, then write model-selection guidance.

Enterprise view

For enterprise admins, Signals is meant to be a session-finding and process-improvement surface. Some patterns start as member-level habits. Others are project, team, or org-level issues from the beginning.

The distinction matters:

• Habit issues usually need coaching or workflow changes.
• Project issues usually need durable context.
• Team issues usually need process changes.
• Org issues usually need policy or installation repair.

A higher-scope signal does not mean every person in that scope caused the issue. It means the repeated evidence is broad enough that fixing only one user may not solve it.

Current limitations

Signals depends on captured data. If sessions are missing, incomplete, or not yet processed, the signal can miss evidence.

Some patterns require specific telemetry. P9 needs provider-reported cache/context data. P6 depends on policy snapshots. P8 depends on similarity data. P10 needs enough matched sessions before it can compare model choices fairly.

Some patterns also require judgment. P4 can show that a session waited, but not why the user waited. P10 can show that a lighter model worked for comparable historical sessions, but not guarantee that the lighter model is always safe for future work.

That is the intended contract: Signals should reduce the search space, not replace review.

If a signal feels noisy, missing, or incorrectly scoped, we want that feedback. The thresholds are calibration points, and the most useful improvements will come from real teams reviewing the evidence and telling us where the pattern helped or where it got in the way.