The 11-by-11 tipping point: when AI savings start compounding

11 minutes a day. 11 weeks. That is the threshold Microsoft's WorkLab research found separates AI that gets used from AI that gets quietly abandoned. Below it, every agent in your stack is a novelty. Above it, work patterns shift and people stop noticing the agent is there. The number is not a productivity target, it is a habit-formation threshold, and the difference matters when you decide which automation to scale and which to cut.

What 11-by-11 actually measured

The Microsoft Copilot Usage in the Workplace survey tracked early Copilot users over 11 weeks and found a clean inflection. At week 11, users who were saving roughly 11 minutes a day reported four things shifting at once: productivity, work enjoyment, work-life balance, and the ability to skip meetings. Before that point, the same users described Copilot as helpful but optional. After it, they described it as part of how they work.

The raw savings number was actually higher. The average user saved 14 minutes a day. The most efficient saved 30. But 11 was the floor where the behaviour stuck. Below the floor, people kept reaching for the old workflow.

That floor matters because most AI ops dashboards do not track it. They track total hours saved, which adds up minutes from agents that fired 12,000 times last month and minutes from agents that fired 200 times. The 12k-execution agent could be saving 1 minute per run on a task nobody cares about, and it would still look like a winner on the summary line. The 200-execution agent could be on a trajectory that crosses 11-by-11 in week 8 and looks like a rounding error in the same dashboard.

Why this matters for ops prioritisation

The 11-by-11 frame flips the question. Instead of "which agents save the most hours this month", ask "which agents have crossed the threshold where the team has internalised them, and which are still in novelty territory".

The first group can be left alone. They have already changed how the work happens. Cutting one of them means rebuilding a habit, which is expensive and slow.

The second group is the active decision queue. Some of them are climbing. Some of them have flatlined at 4 minutes a day and will never compound. The ops job is to tell those two apart before the budget review.

A typical n8n stack running between 1,000 and 100,000 executions per month, the documented range for n8n Insights, will have 20 to 80 agents in active use. Maybe a third of them have passed 11-by-11. The rest sit in a long tail where the trajectory tells you more than the absolute number.

The leading indicator

The signal that predicts whether an agent crosses 11-by-11 is the weekly minutes-saved-per-active-user trajectory, measured against the same user cohort week over week.

Three patterns show up in the data:

1. Climbing. Week 1: 3 min/day per active user. Week 4: 7 min. Week 8: 10 min. Week 11: 12 min. Crossed. Scale it.
2. Flat. Week 1: 4 min/day. Week 4: 4 min. Week 8: 4 min. Adoption is real, the habit is not. The agent solves a problem nobody had, or solves it in a way that does not compound. Retire or rework.
3. Decaying. Week 1: 9 min/day. Week 4: 6 min. Week 8: 3 min. People tried it, then stopped. Either output quality dropped or the original need disappeared. Investigate or kill.

The trajectory is the leading indicator. The hours-saved total is the lagging one. By the time the lagging number shows the cliff, the budget conversation is already underway.

The payload field that lets you compute trajectory

Computing the curve per agent needs two things in every tracked execution: the agent identifier and the user identifier. Without both, you cannot distinguish "10 users each saving 1 minute" from "1 user saving 10 minutes", and only the second pattern crosses 11-by-11.

A minimum savings event looks like this:

{
  "agent_id": "ticket_router_v3",
  "task_type": "ticket_routing",
  "user_id": "u_8842",
  "outcome": "success",
  "human_baseline_minutes": 4,
  "metadata": {
    "workspace": "support",
    "source": "n8n"
  }
}

With that payload, the weekly trajectory falls out of a single group-by on agent_id, user_id, and the ISO week. Cohort users by their first-seen week, average minutes saved per active day per user, and plot 11 weeks forward. Agents whose week-8 reading is above 8 minutes are almost certainly on track. Agents whose week-8 reading is below 6 minutes almost never recover.

The human_baseline_minutes field is the only one that needs calibration. HumanHours' baseline guidance covers the three-step process for setting one that survives a finance review. The rest of the payload is structural and stays constant per agent.

The decision rule

For every agent in the active queue, check the week-8 reading.

• Above 8 minutes per active user per day, trajectory positive: keep instrumenting, prepare to scale the agent to adjacent workflows.
• Between 4 and 8 minutes, trajectory flat: dig into why. Usually a UX issue (the agent is one click away from the workflow it should be inside) or a quality issue (the output needs review more than half the time).
• Below 4 minutes after week 8: cut it. The compounding will not happen, and the running cost is real.

This rule does not need a dashboard built specifically for it. It needs the savings event schema to carry user_id, and one weekly query that the ops lead actually reads before the budget review. Most AI ops setups have neither, which is why most AI portfolios still get cut on the wrong agents.