The Feedback Loop: Friction, Usage, and Safe Automation

TeamAI’s improvement layer is designed to answer a selective question: which parts of an AI-assisted session are worth turning into team capability? This chapter follows the path from lifecycle hooks to local events, friction scoring, aggregate reporting, and safety controls. The practical judgment it supports is whether TeamAI is collecting useful feedback—or merely counting activity—while keeping detailed session context and privileged automation within explicit boundaries.

That distinction matters because an agent session contains both routine motion and meaningful evidence. A member may spend ten minutes making ordinary edits, or they may interrupt the agent, reject a tool call, correct a wrong direction, or watch it retry a failing command. The latter signals that something about the interaction, the team’s instructions, or the surrounding system deserves attention. TeamAI’s current design tries to notice that difference without requiring a person to classify every session manually.

Select friction, not volume

TeamAI’s hooks create the raw observations. Session start, post-tool use, prompt submission, and stop events can be sent to the dashboard collector. The collector identifies the session, working directory, tool, and lifecycle event. On prompt submission it keeps a bounded prompt summary; on Stop it can inspect the host transcript for the last assistant output, user interruptions, rejected tool calls, failing-tool retries, human prompt turns, and token usage. The result is an append-only local event stream from which session state and metrics can be reconstructed.

The contribution check does not immediately read and analyze the whole event log after every tool call. It maintains per-session state and first applies a fast activity gate. In the current snapshot, a session needs at least 15 tool-use events before a friction-heavy interaction can qualify for a share hint. That gate matters because a single rejected command may be informative to the person involved without being substantial enough to become team knowledge.

Once the activity gate is reachable, the score gives priority to signals of struggle. One user interrupt, one rejected tool call, or one course-correction prompt contributes 20 points in the current implementation. Failing-tool retries use a gradient: three retries contribute less than five, and eight or more contribute more, so a single fluke error does not carry the same weight as repeated failure. Skill use and tool diversity add only a small scale bonus. They can make a substantive session more legible, but they cannot create the hint by themselves.

This is a proxy, not a measurement of learning value. A user may interrupt an agent for a harmless preference, or a session may contain an important discovery without an obvious friction signal. TeamAI’s logic therefore treats the score as a threshold for asking whether the session is worth documenting, not as a final classification of the session. The current smart threshold is 20 points, but those values are implementation constants and can change; the durable design principle is friction plus substantive activity, not the number itself.

Recall participates in the decision as another signal. If the session searched the team knowledge base and received no useful result, or only a very low-quality result, the contribution check can add a knowledge-gap bonus. That lets a difficult session reveal two things at once: the agent encountered friction, and the team’s existing context did not cover the task well. A Git commit is neutral in the current adjustment; completing work is not treated as proof that the resulting session deserves to be shared.

When a session qualifies, TeamAI builds a hint that explains why: the user interrupted the AI, rejected a tool call, corrected it, or the AI retried failing tools.