# How it learns

Source: https://routineos.org/concepts/learning

> A routine learns from records you keep or drop, then proposes one settings change with its evidence. You accept, reject or snooze. It cannot self-apply.

How it learns

# Code counts. The routine suggests. You decide.

A RoutineOS routine learns from what you do with its results, then asks. It does not apply its own suggestion: only your Accept changes a setting. Learning is built and tested, and has not been run against a live routine.

[Get started](https://routineos.org/#start)[See Inbox triage](https://routineos.org/templates/inbox-triage)

from the docsbuilt and tested, not yet run on a live routine

The loop

## A self improving AI agent that stays in your control

The loop is run, work, count, suggest, decide. People correct routines all the time, and most of those corrections are thrown away. Learning keeps them. If you keep five roles the settings dropped, you are telling the routine its settings are wrong.

1. **The routine runs.**It finds records and the settings keep or drop each one, with a reason.
2. **You work on the Desk.**You keep a record the settings dropped, or drop one they kept.
3. **Code tallies the gap.**Plain code counts the difference between what the routine did and what you did. The model does no counting.
4. **A threshold decides.**A suggestion is raised only when enough of your decisions agree. The defaults are at least 5 records, and at least 60% of them.
5. **The model words it.**It writes the title and the reason in plain language. It cannot change the change itself.
6. **You decide.**One card lands in your Inbox and on the Suggestions page. You accept, reject or snooze it.

An example

## "Add hydrogen to title_keywords"

This is the worked example from the docs, on the Hiring Signals routine built from [Jobs watch](https://routineos.org/templates/jobs-watch). In one run, six roles with titles like "Hydrogen Developer" were dropped because they did not match `title_keywords`. On the Desk, the person kept five of them.

On the next run the routine raised one suggestion, with the evidence attached: you kept **5 of the 6** dropped records, and they carry the word. Accepting it adds the word to the setting and records the decision. From the next run, those roles are active.

Add hydrogen to title_keywords signal: uncaptured_term evidence: you kept 5 of 6 dropped records [ Accept ] [ Reject ] [ Snooze ]

What it counts

## Five signals, all counted by code

A signal is on unless the definition turns it off.

| Signal | The gap it counts |
|---|---|
| `override` | You kept a record that a setting dropped. |
| `uncaptured_term` | Records you kept, that an include filter missed, share a plain word. |
| `dead_item` | A list item matched nothing for 10 runs in a row (the default). |
| `limit_pressure` | Runs offered more Inbox messages than a declared limit allowed. |
| `people_drop` | You dropped records the routine kept, and they share a word. It proposes excluding that word. |

Four more signals are named in the docs but not counted yet: `source_health`, `connections`, `edit_drift` and `manual_repetition`. None of the counted signals read gate decisions today. Learning reads your keep and drop decisions on the Desk.

Guardrails

## What a routine is not allowed to learn

- It does not apply its own suggestion. Only your Accept changes a setting.
- It cannot learn sending, alerts or what may leave the routine. The write step refuses settings that control these. [See the list in the docs](https://docs.routineos.org/guides/tune-learning).
- It raises no suggestion the code did not count. The model words a suggestion but cannot create one, and the write step refuses any that code did not count.
- The prompt tells the routine to treat fetched pages as data, and a proposed value may only be a short plain word or phrase.
- It does not ask again right after a no. A reject blocks the same suggestion for 14 days by default, and a snooze holds it until the date you set (7 days on the Desk).

**Levels**The first level changes one setting value, and Accept applies it. Two higher levels, a definition change and a workflow or prompt change, are for a person to carry out. Today, on those two levels, an accepted card records the decision only. No pull request is opened yet.

With a team

## Learning from people who join your Desk

Since 0.8.0, a Desk can be open to teammates. The owner's learning reads the owner's decisions and each worker's decisions. A suggestion then says whose decisions it came from, for example "From 7 decisions by you and 5 by a teammate (sender lane)".

A worker learns only from their own decisions. Only the owner applies a suggestion. [Read how joining a Desk works](https://routineos.org/concepts/join-a-desk).

The off switch

## Switch it off, or just say no

You can turn learning off for a whole Desk. Tallies still count, nothing is proposed, and the write step refuses every suggestion. You can also turn off one signal in a routine's definition. To silence one suggestion, reject it, and rejection memory holds it back.

Learning needs decisions. With the default of 5, you will not see a suggestion after one run. [Read how to tune learning](https://docs.routineos.org/guides/tune-learning).

**Honest limit**Learning is built and tested in code, but has not yet been run on a real, live routine. [See the honest limits](https://docs.routineos.org/introduction/honest-limits).

## See it in the Inbox triage template

An approval-gated routine that waits for your yes. Learn more about [how RoutineOS works](https://routineos.org/concepts), or read the full [lifecycle](https://routineos.org/lifecycle).

[Get started](https://routineos.org/#start)[Read the docs](https://docs.routineos.org/concepts/learning)