Bounded managed-loop policies

Set AgentConfig.loopPolicy or RunOptions.loopPolicy to add bounded recovery and host completion checks to managed run/stream. null disables a configured policy for one execution. Without a policy, existing behavior is preserved.

The shared allowance defaults to two recovery interventions. Failed actual tools, repeated normalized read observations, optional unchanged host progress keys and false completion predicates consume it. Repeated admitted writes/unknown effects stop before replay; uncertain outcomes require host inspection. Application success:false data does not become a framework failure.

completion(context) is host-owned and checks actual required state/evidence; return {complete, reason?, feedback?}. A successful model response or submitted job alone is insufficient. Optional response.loop/existing stream-event loop metadata and agent.getLoopDiagnostics() report phase/reason/workflow status separately from provider status and assistant text. Missing completion callbacks yield an ordinary answer without a workflow completion assertion.

Checks receive bounded frozen observations/task state and a cancellation signal; they are timed, validated and rejected on stale task/owner/conversation identity. Callbacks/counters are not session authority and are never restored. Use explicit ModelTask sharing for helper checks and inspect actual model-call usage.

With the policy enabled, stream invokes shared before:tool preparation; the unconfigured legacy trace remains unchanged. Streamed candidate text stays provisional. JSON final repair remains run-only. Async/suspended work retains waiting-external semantics. Direct, realtime and external SDK-owned loops remain outside this policy. Read the complete recipe for limits, effects, persistence and exact support boundaries. Build first and run npm run example:feedback-agent, npm run example:loop-equivalence, or npm run example:amos-loop offline. npm run test:loop:live opts into billable three-provider checks. See release status.

Local helper validation and completion scope

Optional HelperCallOptions.validationSchema is an additional synchronous local JSON schema. Both it and schema must pass inside the same zero-or-one repair allowance. It appears as prompt guidance while native response_format stays portable; it cannot weaken schema. Invalid schemas fail before packet building, and repair uses the selected evidence and existing task/input/output/deadline bounds.

Automatic structured compaction uses this to reject all-empty summaries and blank/overlong entries before helper success. Actual Google recovery from the recorded empty body is now verified without masking fallback. Standalone summary callbacks retain one invocation and the existing transaction/fallback behavior. Pending loop completion/progress checks also reject changes to tool principal, account/connector selections, identities, roles, session or connector authority. See helpers for local validation and repair bounds.