triago's whole premise is that an agent reaches for it without being told to. It wasn't doing that, and the reason turned out to be one sentence missing from the instructions.
What was wrong
A client carrying a large toolset can defer an MCP server's tools to a name-only listing — present as names, callable only once their schemas are loaded. The shipped policy read call triago_post_findings instead of printing them, which presumes the tool is already to hand.
So at the exact moment that matters — a review is finished, the list of findings exists, and the agent decides what to do with it — printing costs nothing and posting costs a lookup the agent was never told to make. It printed.
The instructions now say the tools may need loading, and to load them. The note sits inside When to use it rather than at the end, because the tail of a long instructions string is the first thing a host truncates, and a trigger that survives truncation is no use if the means of acting on it doesn't.
Measured, not assumed
The same prompt, in the same workspace, before and after:
| before | after | |
|---|---|---|
| findings produced | 7 | 11 |
| tool loaded | only when asked | unprompted |
| card posted | only when asked | unprompted |
Before, the agent printed a section headed "Findings, worst first" with seven numbered items and asked which to fix — the trigger condition stated about as plainly as it can be. After, it loaded the tool on its own and posted eleven findings, keeping the three most serious in the terminal and sending the rest to the card.
An earlier theory held that the trigger was losing because the instructions get truncated. That didn't survive checking: the five-findings threshold sat above the cut in both sessions. It was never a delivery problem — the rule arrived, and pointed at something the agent wasn't holding.