Review policy suggestions

Settings → AI Configuration → Learning is the review queue for suggested changes to your tool, budget, and model policies. It needs the view_policy_learning permission.

The loop is deliberately one directional: something observes how work actually ran, proposes a change, and a person decides. Nothing on this page changes a policy without you.

Where suggestions come from

Once a day, at 08:00 UTC, the platform sweeps your workspace: it reads a trailing seven days of your own activity, runs each rule over it, and queues anything that crosses a threshold. Run a sweep now does the same pass on demand.

There are four inputs, and each feeds particular rules:

Signal	What it produces
Incidents raised on your work	Sandbox requirements on a tool, tighter budget caps
Task costs, measured against your budget caps	Budget suggestions
Model latency, recorded per model call	Moving one section of the app onto a different model
Tool response sizes, reported by your runners	Response size caps on a tool

The last two are measured rather than assumed, so a workspace not producing them yet gets no suggestion of that kind. The page says which of the four it can see, so an empty queue is never a mystery.

A model suggestion is the one to read most carefully. It proposes moving one section of the app (huddles, coding, review, and so on) onto a different model, and the replacement is always drawn from the allowlist you set in the model catalog. If you remove a model from the allowlist after a suggestion naming it was raised, applying that suggestion fails rather than routing you onto it.

Read one

Each suggestion carries:

• The kind and the risk, stated by the simulation. High risk means the change reaches a lot of work, not that the platform is unsure.
• What it applies to: a tool, a section, or a task type. Some budget changes apply to the whole workspace, and say so.
• The sample size, in the card header. A suggestion drawn from 12 observations and one drawn from 12,000 are different decisions, so the number comes before anything else.
• The rationale: the observation behind it, in a sentence.
• What was observed: the measured figures the rule fired on. A figure the platform did not measure is left out rather than shown as zero.
• What is projected: the estimated saving, latency change, calls blocked, and tasks affected.
• The proposed change, behind View the proposed change.

Read the rationale before the change. Tightening a budget because a class of task kept breaching its cap is a different decision from the same change proposed because one task was unusual.

Decide

• Apply this change approves the suggestion, writes the change, and records the previous value. Both steps land in the audit log under you.
• Reject declines it, with a reason you type.
• Roll this change back restores the previous value. It is available on applied suggestions only, which makes applying a reversible act rather than a commitment.
• Re-run the simulation recalculates the projected figures, changing nothing.

Every decision is recorded in the audit log under the person who made it.

An empty queue

An empty queue means one of two things, and the page tells you which.

Nothing to suggest from the last sweep. Every signal was readable and none argued for a change. All five are listed with how much the last seven days held. A signal with nothing in it is normal: no incidents is good news, not a gap.

Some signals are not being collected yet. At least one rule had nothing to judge. The page names which, and how many calls went by without the measurement. Model latency and tool response sizes are the two you are most likely to see here.

Both states end with when the sweep last ran and what it did, or a plain statement that no sweep has run yet.

When a suggestion returns

The daily sweep is idempotent. A finding already in your queue is not added twice, it is re-stamped with today’s figures, so the queue shows what is true now rather than growing a duplicate every morning.

A rejection is remembered. The same finding is suppressed for 90 days. If it returns after that, the new card carries your earlier rejection forward: the date, who declined it, and the reason. That is what makes writing a reason worth the twenty seconds.

Suggestions nobody acts on

An open suggestion nobody decides on expires after 30 days and drops out of the queue. That window is far wider than the seven day signal window on purpose: a finding that keeps recurring is re-observed and its clock resets daily, so only findings that genuinely stopped happening age out.

A working order

1. Leave suggestions alone for a week rather than acting on the first one. A single task is not a pattern.
2. Apply one at a time. Two applied together make the next week’s signals unreadable.
3. Watch the area the change touches for a few days.
4. Roll back rather than tuning around a change that made things worse.

Next steps

• Budgets: the policy most suggestions touch.
• The model catalog: where a model suggestion draws its replacement from.
• The audit log: where applied and rolled-back changes are recorded.