Budgets and limits
Give work a limit as well as an objective, and define what happens when it reaches a boundary.
Choose limits that match the work
The proposed budget model would make permitted effort explicit. A mission could have spending, elapsed-time, or execution-step limits, with clear behavior when a limit is approached or reached.
Research might benefit from a time limit. A connected runtime might need a spending cap. A maximum number of attempts can stop repeated retries from consuming resources without improving the result.
Every limit needs units and a scope. An allowance for one mission should not silently become permission to spend on unrelated work. A task owner should be able to see which allowance applies before beginning.
Decide when to stop
Stop conditions should cover exhausted budgets, repeated failures, missing permissions, and decisions that require a person. Reaching a limit should preserve useful output and explain the next decision, rather than lose the work or continue silently.
Estimates and actual usage must remain distinct. A future system should report measured usage only when its execution environment supplies reliable data.
A bounded research taskSpend up to 30 minutes investigating the release issue. Stop after three unsuccessful access attempts. Ask before using a paid source. Return the findings, incomplete questions, and any measured usage.
Review before extending a limit
- What useful work has already been produced?
- Which dependency or uncertainty remains?
- Would another attempt change the result?
- What new allowance, if any, is justified?
Try the budget control in the product preview to explore the proposed interaction. Enforcement, runtime accounting, and spending reports remain planned capabilities.